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Introduction 


This  paper  is  one  in  a series  describing  the  Alphard  programming  system  and  its 
associated  verification  methods.  It  presumes  that  the  reader  is  familiar  with  the  materal  in 
[Wulf76a,b],  particularly  the  use  of  forms  for  abstraction  3nd  the  verification  methodolrgy  for 
forms. 


The  primary  goal  of  the  form  mechanism  is  to  permit  and  encourage  the  localization  of 
information  about  a user-defined  abstraction.  Specifically,  the  mechanism  is  designed  to 
localize  both  verification  and  modification.  Other  reports  on  Alphard  have  discussed  ways  to 
isolate  specific  information  about  representation  and  implementation;  in  this  paper  we  deal 
with  localizing  another  Kind  of  information. 

Suppose  that  S is  a "set-of~integers"  and  that  we  wish  to  compute  the  sum  of  the 
integers  in  this  set.  In  most  contemporary  programming  languages  we  would  have  to  write  a 
statement  such  as 


sum  <-  0;  for  i <-  1 step  1 until  S.size  do  sum  <-  sum  + S[i] 


o.  possibly 


p <-  S;  sum  <-  0;  while  p / nH  do  (sum  <-  sum  + p.value;  p *-  p.next) 
or,  if  we  know  that  the  set  elements  all  lie  in  the  range  [lb..ubj,  then  we  might  write 

sum*-0;  for.  i«-lb  to  ub  do  if  i < S then  sum«-sum+i 

None  of  these  statements  is  really  satisfactory.  First,  they  all  seem  to  imply  an  order  to  the 
summation,  whereas  the  abstract  computation  does  not.  Next,  the  first  statement  strongly 
suggests  a vector  implementation  of  the  set  and  the  second  a list  implementation.  (Although 
other  implementations  are  not  excluded,  the  resulting  loops  will  probably  be  unacceptably 
inefficient.)  The  third  statement  does  not  suggest  an  implementation  of  the  set,  but  may  be  too 
inefficient  if  the  cardinality  of  the  set  is  much  smaller  than  ub-Jb+1. 

It  would  be  much  better  if  we  could  write  something  like 

sum«-0;  for  x(S  do  sum«-sum+x 

which  implies  nothing  about  either  the  order  of  processing  or  the  representation  of  sets. 
Except  for  notational  differences,  this  latter  example  illustrates  our  goal.  We  want  to 
encourage  suppression  of  the  details  of  how  iteration  over  that  abstract  data  structure  is 
actually  implemented.  The  difficulty  in  doing  this  is  that  the  abstract  objects  are  not 
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predefined  in  Alphard.  Hence  it  is  the  author  of  the  abstraction  who  must  specify  the 
implementation  of  (the  analog  of)  VS" 

We  resolve  the  problem  by  separating  the  responsibility  for  defining  the  meaning  of  a 
loop  into  three  parts.  (1)  Alphard  defines  the  (fixed)  syntax  and  the  broad  outline  of  the 
semantics.  (2)  The  definition  of  the  abstraction  that  is  controlling  the  iteration  fills  in  the 
details  of  the  loop  control  (in  particular,  the  algorithms  for  selecting  the  next  element  and 
terminating  the  loop).  (3)  The  user  supplies  the  loop  body.  Conventional  languages  provide 
only  a small,  fixed  number  of  alternatives  (usually  one)  for  ;he  second  part  of  this  information. 
In  Alpharo  it  is  supplied  by  the  form  that  defines  the  abstraction;  we  say  this  part  of  the 
definition  specializes  the  iteration  statement  to  that  abstraction,  Related  constructs  appear  in 
IPL-V  as  generators  [Newell64]  and  in  Lisp  as  the  mapping  functions  [McCarthy62, 
Weissman67], 

One  of  the  major  goals  of  Alphard  is  to  provide  mechanisms  to  support  the  use  of  good 
programming  methodology.  The  rationale  for  generators  given  above  is  based  on 
methodological  considerations;  that  is,  it  is  generally  good  to  abstract  from  the  implementation 
and  hide  its  details.  Generators  permit  us  to  do  this  for  control  constructs  much  as  the 
functions  in  a form  permit  abstraction  of  operations  (see  [Wu!f76a,b]). 

A second  major  goal  is  to  provide  the  ability  to  specify  precisely  the  effect  of  a 
program  and  then  prove  the  program  implements  that  specification.  To  meet  this  goal,  we 
must  provide  more  than  just  the  language  mechanism  for  generators:  we  must  also  provide 
both  a way  to  specify  their  effects  and  a corresponding  proof  methodology.  A natural  means 
of  doing  this  for  generators  is  somewhat  different  from  one  for  functions.  Functions  are 
naturally  characterized  by  predicates  which  relate  the  state  of  the  computation  before  their 
invocation  to  its  state  afterward.  Generators,  however,  are  not  invoked  in  the  usual  sense; 
rather  they  are  used  to  control  the  repeated  execution  of  an  arbitrary  "body"  of  an  iteration 
statement.  Thus,  a natural  specification  of  a generator  is  in  terms  of  a "proof  rule"  which 
permits  the  effect  of  the  entire  iteration  statement  to  be  expressed. 

This  report  contains  two  strongly  related  components:  first  we  introduce  the  language 
mechanism  for  generators,  then  we  turn  to  the  specification  and  verification  of  generators  and 
of  the  iteration  statements  which  use  them.  We  begin  with  a digression  on  a language  feature 
which  is  not  discussed  elsewhere,  but  is  needed  for  the  definition  of  generators.  We  then 
introduce  the  two  Alphard  iteration  statements  and  show  how  they  can  be  specialized  by  the 
user.  One  of  these  is  an  iteration  construct  designed  for  searching  a series  of  values  for  an 
element  with  a desired  property.  It  should  replace  most  of  the  loop-exit  gotos  used  in  current 
languages.  (Interlisp  [Teitelman75]  contains  a wide  variety  of  iteration  statements,  one  of 
which  specializes  to  this  construct.) 

We  obtain  general  proof  rules  for  the  two  loop  constructs,  then  state  a series  of 
simplifying  assumptions  that  certain  generators  may  satisfy.  We  obtain  a corresponding  series 
of  proof  rules  whose  simplicity  increases  with  the  restrictiveness  of  the  assumptions  we  make 
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about  the  generators.  These  assumptions  lead  both  to  rules  that  correspond  directly  to 
familiar  rules  for  iteration  (e.g.,  those  of  Pascal  [Hoare73,  Jensen74])  and  to  simple  rules  for  a 
substantial  number  of  interesting  abstract  structures  (e.g.,  those  given  by  Hoare  [Hoare72a]). 

We  then  show  how  to  use  proof  rules  instead  of  functional  descriptions  to  specify  many 
of  the  forms  which  define  generators.  We  also  give  a technique  for  showing  that  loops  using  a 
generator  will  halt  (assuming  the  loop  body  terminates).  We  prove,  with  one  application  of 
this  technique,  that  many  common  gsnerators  have  this  property. 

Finally,  we  develop  an  extended  example  in  which  a programmer-defined  abstraction  is 
treated  as  primitive  in  the  implementation  of  another  abstraction.  A generator  defined  in  the 
former  is  used  in  the  implementation  and  verification  of  the  latter. 


Form  Extensions 


In  this  section  we  introduce  another  language  facility  which  makes  It  more  convenient  to 
define  certain  abstractions  and  to  manage  the  definitions  after  they  are  written.  The  facility 
allows  a programmer  to  define  one  form  as  an  extension  of  another.  The  new  form  will  have 
most  or  all  of  the  properties  of  the  old  one,  plus  some  additional  ones.  (This  mechanism  Is 
similar  to,  and  derived  from,  the  class  concatenation  mechanism  of  Simula  [Dahl72].'  We 
introduce  this  mechanism  at  this  point  because  it  Is  needed  for  generator  definitions,  which 
will  be  discussed  in  the  next  section. 

The  following  skeletal  form  definition  illustrates  most  of  the  major  attributes  of  the 
extension  mechanism: 

form  counter  extends  i:integer= 
beginform 
specifications 

initially  counter  = 1; 
inherits  < =,  <,  >,  <,  £ >; 

function 

inc(x:counter) . . ., 
dec(x:counter) . . .; 
representation 
init  i<-l; 
implementation 

body  inc  ■»  x.i  <-  x.i+lj 
body  dec  ■ x.i  «-  x.i-lj 


endform 
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The  general  flavor  of  the  mechanism  is  that  the  new  abstraction,  “counter"  in  this  case, 
is  to  be  an  extension  of  a previously  defined  one  called  its  base  type,  here  "integer".  As  such, 
the  new  abstraction  inherits  the  indicated  properties  specified  for  the  base  type,  and  may 
appear  in  contexts  where  the  base  type  was  permitted  (e.g.,  as  an  actual  parameter  where  the 
formal  specifies  the  base  form).  Further,  the  new  abstraction  has  the  additional  properties 
specified  in  the  extension  form,  "inc"  and  "dec"  in  this  case. 

Even  though  the  newly  defined  form  is  an  extension  of  another,  the  body  of  the  new 
form  is  not  granted  access  to  the  representation  of  the  old  one;  the  only  access  rights 
granted  to  the  body  of  the  new  form  are  those  defined  in  the  specifications  of  the  one  being 
extended.  Thus,  although  the  extension  may  add  (and  delete,  see  below)  properties  of  the 
extended  abstraction,  it  cannot  affect  the  correctness  of  its  implementation,  and  we  need  not 
reverify  the  properties  of  the  original.  (Indeed,  since  these  properties  are  identical  we  do  not 
demand  that  they  even  be  specified.) 

In  this  example,  and  indeed  more  generally,  it  is  not  desirable  for  a U of  the  properties 
of  the  old  abstraction  to  be  inherited  by  the  new  one.  The  "<>"  notation  may  be  used  as  in 
[Wulf76a,b]  to  list  the  rights  that  the  instantiation  of  the  new  abstraction  is  allowed  to  inherit. 
Thus  the  maximum  set  of  rights  permitted  to  the  instantiation  of  a "counter"  is  the  union  of  the 
inherited  rights  (=,/,<,',<,>)  and  the  newly  defined  rights  (inc  and  dec).  Note  in  particular  that 
assignment  to  a cour.ter  is  not  one  of  the  inhe-ited  rights;  thus  the  only  way  to  achieve  a 
side  effect  on  a counter  is  through  the  operations  "inc"  and  “dec".  The  implementation  of  the 
extension  form  may,  of  course,  use  all  operations  On  the  base  type. 

As  a practical  matter,  the  instantiation  of  the  base  form  (V  from  "i:integer"  in  this 
example)  may  be  considered  a part  of  the  representation  part  of  the  extended  form.  Note, 
however,  that  this  need  not  be  the  .entire  representation  part  of  the  extension;  in  many  cases 
the  extension  will  involve  additional  data. 


Iteration  Constructs  in  Alphard 


Alphard  provides  two  iteration  commands:  the  for.  statement  is  used  for  iteration  over  a 
complete  data  structure,  and  the  first  statement  is  used  (primarily)  for  search  loops.  As 
mentioned  above,  each  of  these  commands  may  be  specialized  for  each  use.  Specialization 
information  is  provided  through  a standard  interface  called  a generator.  A generator  is  itself 
simply  a form,  but  it  must  adhere  to  certain  special  requirements  that  make  it  mesh  with  the 
semantics  of  iteration  statements: 


(a)  It  must  provide  two  functions  (named  &init  and  &next)  with  properties 
described  below. 
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(b)  Invocati  these  functions  in  a prescribed  order  must  produce  a sequence 
of  value i , , Dind  to  the  loop  variable.^ 

(c)  It  must  be  an  extension  whose  base  type  is  the  same  as  the  type  of  the 
elements  being  supplied  to  the  loop  body. 

Before  we  discuss  generators  intended  for  specific  structures,  we  will  illustrate  the  use  of  the 
for  and  first  statements  with  simple  counting  loops. 


The  for_  Statement 

We  shall  begin  with  the  for  statement.  The  syntax  for  the  statement  is*- 

for  x:  gen(y)  while  ft(x)  do  ST(x,y,z) 

where  /?(x ) is  an  expression,  the  statement  $T(x,y,z)  is  the  loop  body,  x is  the  instantiation  of 
the  generator  "gen",  y is  the  set  of  instantiation  parameters  to  the  generator,  and  z is  the  set 
of  other  variables  used  in  the  statement.  The  phrase  "x:  gen”,  which  is  our  notational  analog 
of  the  "xcS"  in  the  introduction,  means  "bind  x to  an  instantiation  of  the  generator  named  gen 
intended  specifically  to  generate  the  elements  specified  by  y”.  Then  x may  appear  free  in  ft 
and  ST;  like  any  loop  variable,  x is  rebound  for  each  pass  through  the  loop. 

The  meaning  of  the  foj_  loop  is  given  by  the  statement 

begin  local  x:  gen(y); 
n <-  x.&init; 
while  n cand  ftM  do 

(ST(x,y,z);  n <-  x.&next) 

end 

Here,  cand  is  the  "conditional  and"  operator:  "bj  cand  ■ "it  bj  then  b2  else  false".  A!so,  ft 
and  ST  are  taken  from  the  for  statement,  and  x.&init  and  x.&next  are  functions  supplied  by  the 
generator  as  described  below.^  The  compiler-generated  variable,  n,  is  not  accessible  to  the 


1 Although  we  call  this  a "loop  variable",  it  will  not  normally  be  possible  to  alter  its 
value  within  the  loop  body. 

2 Either  "for.  x:gen(y)"  or  "while  ftW  may  be  omitted  yielding  the  pure  while  and  pure 
for  statements,  respectively.  If  "while  ftM"  is  omitted,  ft  is  assumed  to  be  identically  true.  If 
"for  x:  gen"  is  omitted,  no  x is  declared  or  set,  ft  and  ST  (clearly)  cannot  depend  on  x,  and 
&init  and  &next  are  assumed  to  be  the  constant  true,  ft  may  depend  on  y and  z in  addition  to 
x. 
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programmer. 

One  of  the  generators  defined  in  the  standard  prelude  is 

upto(lb,ub:  integer)  extends  k:  integer 

This  generator  produces  the  sequence  of  values  <lb,  lb+1,  lb+2,  ....  ub-1,  ub>,  or  the  empty 
sequence  if  lb>ub.  This  generator,  in  combination  with  the  for  statement,  provides  the 
familiar  "stepping"  loop  found  in  nearly  all  programming  languages;  for  example,  an  Alphard 
loop  for  summing  the  integers  from  1 to  n is 

sum  <-  0;  for  j:  upto(l,n)  do  sum  «-  sum+j 

Note  that  two  types  are  involved  in  this  example.  We  said  in  earlier  contexts  that  the  notation 
"j:  upto(.  .)"  means  "bind  j to  an  instantiation  of  upto".  This  implies  that  the  type  of  j is 
"upto".  However,  notice  that  ] is  used  in  the  body  of  the  loop  as  though  it  were  an  integer. 
This  is  possible  because  of  the  extension  mechanism  described  in  the  previous  section. 
Although  the  apparent  type  of  j is  upto,  form  upto  extends  integers,  inheriting  all  operations 
except  assignment  (the  definition  is  given  in  the  next  section).  As  a result,  integer  operations 
on  j are  legal  and  behave  as  expected. 


The  first  Statement 

One  of  the  common  uses  of  loops  is  for  searching  a sequence  of  values  for  the  first  one 
which  passes  some  test.  The  use  of  an  ordinary  loop  construct  for  this  purpose  is  probably 
the  most  common  cause  of  necessary  gotos  in  conventional  programming  languages:  once  the 
test  has  been  satisfied,  there  is  no  reason  to  continue  executing  the  loop.  Since  this  case 
occurs  so  often,  Alphard  provides  a special  syntax  for  it.  We  may  write'1* 

first  x:gen(y)  suchthat  /3(x)  then  Si(x,y,z)  else  S2(y,z) 

where  Sj  and  $2  are  statements  and  fi  is  an  expression.  Again,  x is  an  instantiation  of 
generator  gen  and  may  appear  free  in  ft  and  Sj  (but  not  in  S2).  The  meaning  of  the  first  loop 
is  given  by  the  statement 

In  Alphard,  certain  functions  are  given  names  . '’ginning  with  These  are  usually 
functions  provided  by  the  user  to  perform  operations  !H.  t correspond  to  special  constructs  of 
the  language.  Outside  the  form  in  which  they  are  defined,  they  may  not  be  called  by  user 
programs.  In  this  case,  the  for  loop  expects  to  call  functions  named  &init  and  &next  with 
certain  specified  properties.  Alphard  prevents  a user  from  calling  them  explicitly  --  to  skip 
iterations  in  a loop,  for  example. 

^ Either  "then  SI"  or  "else  S2"  may  be  omitted;  an  omitted  clause  is  assumed  to  denote 
the  empty  statement. 
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begin  label  X; 

begin  local  x:  gen(y); 
n *-  x.&init; 
while  n do 

if  fiM  then  (S  j(x,y,z)i  goto  X)  else  n «-  x.&next 

end; 

s2<y  ,z); 

X.  end 

As  above,  the  compiler-gsnerated  names,  n and  X,  are  not  accessible  to  the  programmer. 

In  [Wulf76a,b]  we  presented  a subroutine  to  compare  two  vectors  of  arbitrary  (but 
identical)  types  and  index  sets.  The  subroutine  presented  there  was  phrased  in  terms  of  an 
Algol-like  for  loop.  It  can  now  be  written  in  real  Alphard  using  the  first  statement:"3 

function  eqvecs(A,B:  vector(?t<^>,?lb,?ub))  returns  (eq:  boolean)  - 
first  i:  upto(lb,ub)  suchthat  A[i]  t B[i]  then  eq  «-  false  else  eq  <-  true 

It  does  not  matter  what  the  bounds  of  the  two  vectors  are,  as  long  as  they  are  the  same.  In 
this  case,  we  are  not  relying  on  the  procedure  return  or  an  explicit  escape  to  terminate  the 
loop  early  in  the  care  of  inequality;  that  is  handled  by  the  first  statement.  The  proof  of 
"eqvecs"  will  be  given  in  a later  section. 

We  have  introduced  Alphard  loop  constructs  by  comparing  them  to  simple  counting 
loops.  This  is  the  first  step  toward  solving  the  problem  of  sequencing  over  arbitrary 
structures  under  the  control  of  the  defining  type.  We  shail  now  show  how  generators  and 
loops  are  verified. 


Defining  and  Verifying  Generators 


We  said  that  a generator  is  a form  which  supplies  special  functions  and  performs  a 
sequence  of  bindings  to  the  control  variable  of  the  loop.  In  this  section  we  will  show  how  a 
generator  is  defined  and  invoked,  still  using  "upto"  as  an  example.  We  will  first  present  its 
definition,  then  add  assertions,  verify  it  as  a form,  and  establish  its  special  properties  as  a 
generator.  Another  generator  is  verified  as  part  of  the  finite  sets  example  in  the  sequel. 


5 in  this  example  the  function  specification  and  the  function  body  are  given  as  one 
declaration.  This  is  an  obvious  abbreviation  of  the  notation  used  elsewhere.  The  ?cdentifier 
notation  is  used  to  indicate  that  the  values  of  these  parameters  must  be  identical  for  A and  B 
and  that  specific  values  will  be  supplied  implicitly  with  the  vectors.  This  is  explained  in 
[Wulf  76a,b], 


The  definition  of  the  "upto"  generator,  without  verification  information,  is 


form  upto(lb,ub:  integer)  extends  k:integer  - 
beginform 
specifications 

inherits  <allbut  «->; 
function 

&init(u:upto)  returns  <b:boolean), 

&next{u:upto)  returns  (b:boolean); 
implementation 

body  &init  = (u.K  <-  u.lb;  b «-  u.lb  < u.ub); 
body  &next  = (u.k  <-  u.k+1;  b <-  u.k  < u.ub); 
endform 

Since  no  variables  other  than  k are  needed,  the  representation  part  is  empty  at  this  point. 
This  form  extends  integers,  but  does  not  pass  along  the  right  to  assign  to  an  upto;^  this 
prevents  the  user  from  changing  the  loop  variable  during  the  iteration. 

Using  this  form  and  the  moaning  of  the  for  statement  given  in  the  previous  section,  we 
can  exhibit  a loop  that  corresponds  to  the  expansion  of  the  "upto"  functions  in  the  statement 
for  summing  integers.  This  code  is,  of  course,  only  suggestive,  but  it  illustrates  an  expansion 
which  a compiler  might  reasonably  produce.  Note  that  an  obvious  optimization  has  been 
applied;  later,  when  we  exhibit  the  formal  specifications  of  "upto",  the  value  of  the  iteration 
variable,  x,  will  turn  out  to  be  irrelevant  when  &init  or  &next  returns  false. 

sum  <-  0; 
benin 

local  x:  upto(lb,ub); 
x «-  x.lb; 

while  x<x.ub  do  (sum'-sum+x;  x<-x+l); 

end 


Since  "upto"  is  a form,  we  can  verify  the  form  properties  as  described  in  [Wulf76a,b] 
and  summarized  in  Appendix  A.  Adding  verification  information  in  italics,  the  definition  of 
"upto"  becomes 


6 The  phrase  ' allbut  means  that  all  integer  functions  except  «-  are  applicable  to  the 


upto. 
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form  upto(!b,ub:  integer)  extends  k:  integer  = 
beginform 
specifications 
requires  true; 
inherits  <al ibut  «->; 

Let  upto  = fib.. u.b I where  Lb  < ub  ? upto  = /lb..k-l  Jfk/fk  + l..ub/; 
Lni/ariani  true; 
initially  true; 
function 

&init(u:upto)  returns  (b:boolean) 
post  (b  = lb<ub)  a C6  p lb=k<ub), 

&next(u:upto)  returns  (b:boolean) 
pre  Lb  < k < ub 

post  (b  s k'<ub)  A (b  p k=k'*l  A Lb*k<ub}, 
representation 

rep(k)  = i£Lb<ub  then  /Lb..k-1  ]fk Ifk-1 l..ub  / else  (J; 
invariant  true; 
implementation 

body  & i nit  out  (b  s Lb<ub)  a (6  p Lb-k<ub)  * 

(u.k  «-  u.ib;  b *-  u.lb  < u.ub); 

body  &next  in  Lb<k<ub  out  (b  ~ k’<ub)  A (b  p k = /c’+i  A Lb<k<ub)  = 
(u.k  <-  u.k+1;  b *-  u.k  < u.ub); 
endform 


The  abstract  specifications  describe  an  "upto"  as  an  interval  [lb..ub];  since  the  form  upto 
extends  the  integer  k,  a direct  reference  to  a loop  variable  of  type  upto  will  access  k,  the 
current  value  of  the  loop  counter.  We  will  find  it  useful  later  to  view  the  upto  as  the 
concatenation  of  the  interval  already  processed  ([lb..k-l]),  the  current  element  ([k]),  and  the 
interval  yet  to  be  generated  ([k+l..ub]).  Either  k stays  between  the  endpoints  of  the  interval 
[lb..ub]  or  the  interval  is  empty.  This  is  enforced  by  the  phrase  lb<k<ub  which  appears  in  the 
pre  condition  for  &next  and  both  post  conditions. 

Note  that  no  promise  about  the  value  of  k is  made  before  the  loop  starts  (i.e.,  before 
&init  is  called)  or  after  it  has  run  to  completion  (either  &init  or  Snext  returns  false).  The  rep 
function  shows  how  an  interval  is  represented  by  its  two  endpoints  and  the  loop  variable. 
The  post  condition  on  &init  guarantees  that  the  first  element  generated  is  lb,  but  only  if  lb<ub. 
The  pre  condition  on  &next  prevents  &next  from  being  executed  when  there  is  no  valid 
current  element  (in  particular,  Ainit  must  be  called  first).  The  post  condition  on  &next 
guarantees  that  generated  values  are  consecutive  and  that  the  generator  stops  at  ub. 

For  "upto"  the  four  steps  which  are  required  to  verify  the  form  properties  are  quite 
simple.  (Note  that  the  "u."  qualification  on  u.lb,  u.k,  and  u.ub  is  omitted  for  simplicity.) 
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Defining  and  Verifying  Generators 


For  the  form 

1.  Representation  validity 
Show:  true  o true 
Proof:  clear 

2.  Initialization 

Show:  true  { } true  a true 
Proof:  clear 

F or  the  function  Sunit 

3.  Concrete  operation 

Show:  true  { k <-  lb;  b *-  lb  < ub  } (bslb<ub)  a (bolb=k<ub) 

Proof:  Using  the  assignment  axiom,  the  expression  becomes 
true  ^ (lb<ub  s lb<ub)  a (lb<ub  o lb=lb<ub) 
which  surely  holds. 

4.  Relation  Between  Abstract  and  Concrete 

Corresponding  abstract  and  concrete  assertions  are  identical  and  the  rep 
function  performs  a direct  mapping,  so  the  proofs  are  clear. 

F or  the  function  &next 

3.  Concrete  operation 

Show:  lb<k<ub  { k k+1;  b k<ub  } (bik’<ub)  a (b=>k=k’+l  A lb<k<ub) 
Proof:  Using  the  assignment  axiom,  the  expression  becomes 

lb<k<ub  s>  (k+l<ub  s k’<ub)  A (k+l<ub  o k+l-k’+l  a lb<k+l<ub) 
which  holds  because  k’=k  is  an  implicit  hypothesis  of  the  antecedent. 

4.  Relation  Between  Abstract  and  Concrete 
Same  as  &init.4. 


QED 


To  emphasize  that  a generator  is  a form,  we  will  now  give  an  example  in  which  a 
generator  is  instantiated  in  one  place  and  used  in  another.  The  following  procedure  is  a 
generalized  sum  routine  Its  parameter  is  an  instantiation  of  a generator  and  its  result  is  the 
sum  of  the  elements  produced  by  that  generator.  For  simplicity,  this  procedure  sums  only 
integers.  That  restriction  can  be  relaxed,  but  to  do  so  would  take  us  into  parts  of  Alphard  not 
discussed  in  this  paper. ^ 

7 The  difficulty  is  not  defining  the  type  of  the  output,  which  would  be  expressed  as 

function  ISUM  (g:  9T<generator  extends  ?S>)  returns  (sum:  S) 

but  rather  the  fact  that  we  need  to  initialize  sum  and  do  not  know  the  identity  for  "+"  in  type 

S.  One  solution  is  to  treat  the  first  generated  element  differently  from  the  rest,  and  we  have 
deferred  discussion  of  the  richer  possibilities  of  generators  to  a later  paper. 


Definition 

function  ISUM  (g:  ?T<generator  extends  integer)  returns  (sum:  integer) 
begin 
sum  4-  0; 

for  g do  sum  4-  sum  + g; 
end 

Examples  of  Use 
begin 

local  v:  vector(integer,l,n), 
ig:  upto(l,m),  vg:  invec(v), 
ssum,  vsum:  integer; 

ssum  «-  ISUM  (ig); 
vsurr,  4-  ISUM  (vg); 
end 

This  small  program  declares  five  variables,  The  first,  v,  is  a vector  of  integers  indexed  from  1 
to  n.  The  next  two,  vg  and  ig,  are  (instantiations  of)  generators;  ig  is  an  instance  of  the  upto 
we  have  been  discussing  and  vg  is  an  invec,  which  we  assume  is  defined  along  with  vectors 
and  generates  the  elements  of  the  vector  named  as  its  instantiation  parameter.  The  last  two 
variables,  ssum  and  vsum,  are  simple  integers.  The  first  call  on  ldUM  uses  ig  (the  upto)  to 
generate  integer  values;  it  assigns  to  ssum  the  sum  of  the  integers  from  1 to  m.  The  second 
call  on  ISUM  uses  vg  (the  invec)  to  generate  vector  elements;  it  assigns  to  ssum  the  sum  of 
the  elements  of  v. 


Proof  Rules  for  Loops 


In  this  section  we  shall  consider  the  verification  of  Alphard’s  two  iteration  constructs, 
for  and  first.  Specifically,  we  shall  develop  proof  rules  for  these  statements,  discovering  in 
the  process  certain  desirable  properties  for  forms  which  are  intended  to  be  used  as 
generators.  Some  of  these  properties  will  be  required  of  all  generators;  others  will  be 
considered  optional,  but  their  presence  will  substantially  simplify  proof  rules  and  proofs. 

The  development  will  proceed  as  follows,  First  we  shall  consider  a proof  rule  for  the 
for  statement  which  makes  minimal  assumptions  about  the  generator.  This  rule  is  derived 
directly  from  the  statement’s  meaning  as  given  earlier.  As  a consequence,  it  is  rather  bulky. 
Then  we  shall  make  a small  number  of  basic  assumptions  about  the  generator.  For  purposes 
of  this  paper,  these  assumptions  will  be  required  of  all  generators  and  hence  will  have  to  be 
discharged  when  the  generator  is  verified  as  a form.  They  will  allow  us  to  simplify 
substantially  the  proof  rules  for  the  for  and  first  statements.  Next  we  shall  consider  a further 


set  of  assumptions  about  generators;  these  assumptions  are  not  mandatory,  but  they  are 
satisfied  by  typical  generators.  These  will  allow  us  to  obtain  shll  simpler  proof  rules  for 
particular  generators,  Finally,  we  shall  consider  the  properties  that  a generator  must  have  in 
order  to  be  a terminating  generator. 


Development  of  the  far  Rule 

Suppose  that  we  wish  to  prove 

P { f_or  x:gen(y)  while  ftM  do  ST(x,y,z)  | l(x,y,z)  } Q 

where  x,  y,  and  z are  as  defined  earlier  and  the  notation  “P  { loop  | I } Q”  is  used  to  denote  "P 
{ loop  } Q using  1 as  the  loop  assertion  (invariant)  placed  after  the  loop  body".  Further, 
suppose  that  we  make  only  the  minimal  assumptions  about  the  form  "gen",  namely  that  it  has 
been  verified  as  a form  and  that  it  supplies  two  functions,  &init  and  &next,  each  of  which 
takes  a single  parameter  of  type  gen  and  returns  a boolean  result.  We  will  also  assume  that 
/3(x)  has  no  side  effects.  We  will  adopt  the  following  notation  in  the  iteration  proof  rules: 

G = abstract  invariant  of  the  generator,  G may  depend  on  x and  y but  not  on  z. 

/?req  = the  usual  requires  clause  of  the  generator,  stating  restrictions  on  y so 
that  the  generator  can  be  instantiated. ^ 

/tf  j = the  j-condition  for  generator  function  f,  e.g.,  post  is  *he  pos* 
condition  for  &init.  /3f  j depends  on  x and  y Only. 

XQ,...,Xp  denotes  the  previously  generated  values  of  x,  it  any. 

Since  the  generator  has  been  verified  as  a form,  we  know 

G A Anit.pre  * n x &init  ) G A ^init.post 

G A ^nextpre  { n * x-*next  5 G A /^next.post 
fire q { init  clause  ) G 

where  init  clause  denotes  the  inh  clause  of  the  representation  part. 

The  expansion  of 


for  x:gen(y)  while  do  ST(x,y,z) 


O 

We  conventionally  use  "/?"  to  name  predicates.  Kence,  e.g.,  ftTeq  is  unrelated  to 

AM. 


as  a standard  while  statement,  including  the  assertions  which  will  be  required  for  verification 
in  the  most  general  case,  is 

assert  P a /?req; 
begin  local  x:  gen(y); 
ajssejl  P a G A /?init.prei 
n «-  x.&init; 
while  n cand  /?(x)  do 
begin 

ST(x,y,z;; 

assert  I a G a /Snextpre; 
n <-  x.&next; 
end; 
end; 

assert  Q 


We  will  give  from  this  expansion  a proof  rule  for  the  most  general  Alphard  for 

statement.  The  standard  while  rule  is  not  directly  applicable  to  this  expansion  because  the 

loop-cutting  assertion  is  located  in  the  middle  of  the  loop  body  rather  than  before  the  test. 
This  assertion  placement  means  the  test  does  not  always  appear  just  before  or  just  after  an 
assertion;  in  two  control  paths  through  the  expansion  (the  third  and  fifth  lines  in  the  proof 

rule  below),  the  test  rr  cand  /?(x)  appears  between  either  the  statements  n<-x.&init  or 

n<-x.&next  and  ST(x,y,z).  To  indicate  in  these  paths  that  n cand  may  be  assumed  between 
the  statements,  the  assume  clause  is  introduced.^  Its  proof  rule  is 

P a Qd  R 


P { assume  Q } R 

Using  the  assume  clause  and  considering  the  five  control  paths  between  assertions,  the 
general  proof  rule  for  the  for.  statement  Is 

P A /*req  t init  clause  } P a pre 
P a G a /^injt.pre  f n *"  1 •'(nA/3(x»  = Q 

P A G a pre  { n <-  x.&init;  assume  ra/?(x);  ST(x,y,z)  } I a G a 7?next  pre 
I A G a /3next.pre  { n <-  x.&next  } =>  Q 

I a G a /?nex{  pre  { n «-  x.&next;  assume  ra/?(x);  ST(x,y,z)  } I a G a /?next.pre 
P a /?req  { for  x:  gen(y)  while  /t(x)  do  ST(x,y,z)  | I } Q 


^ The  assume  clause  appears  in  [Igarashi75,  p.  164]  as  the  "marked"  assertion  using 


the  notation  Q-if  in  place  of  assume  Q. 
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Proof  Rules  for  Loops 


This  formulation,  because  of  its  generality,  may  appear  formidable.  The  main  difficulty 
appears  to  be  that  the  three  generator  functions  and  the  loop  body  may  each  change  y in 
various  ways  even  though  P and  I hold  at  the  places  required  by  the  rule.  The  generator 
functions  are,  therefore,  involved  in  the  verification  of  each  use  of  a generator.  However,  the 
following  three  reasonable  assumptions  about  the  generator  will  simplify  matters  considerably. 

Basic  Generator  Assumptions: 

(a)  The  post  conditions  on  &init  and  &next  are  of  the  form 

(b  s rtj)  a and  (b  s nn)  a /?n 

respectively,  where  b is  the  result  pc.ameter  of  these  functions. 

(b)  G =>  /^init.pre’  ^ A ^niA^init.post  v nnA^next.post^  3 ^next.pre 

(c)  The  init  clause  and  the  functions  &init  and  &next  terminate.  (This  does  not 

simplify  the  proof  rule  It  is,  however,  a desirable  property,  and  it  becomes 

especially  relevant  in  (he  discussion  of  generator  termination  below.) 

(d)  The  generator  and  the  loop  body  are  independent.  Thai  is,  for  arbitrary 

predicates  R and  S 

R(y,z)  { init  clause  } R(y,z) 

R(y,z)  { n <-  x.&init  } R(y,z) 

R(y,z)  { n <-  x.&next  } R(y,z) 
and  S(x,y)  { ST(x,y,z)  } S(x,y) 


Point  (a)  is  a minor  restriction  and  can  be  checked  syntactically.  Point  (b)  requires  two 
proofs.  The  first  is  usually  trivial  since  /^jnj{  pre  is  generally  omitted  (defaulted  to  true)  and 
^next  pre  's  u5uaHy  included  in  both  post  conditions.  G may  often  be  strong  enough  by  itself, 
but  we  may  not  want  to  commit  the  generator  to  provide  a value  at  all  times.  In  the  latter 
case  we  therefore  require  that  &mit  and  &next  make  it  possible  for  &next  to  be  executed. 
Point  (c)  can  be  proved  independently  of  the  use  of  ^rator,  The  proofs  should  usually 

be  easy  (see  the  section  below  on  termination). 

Point  (d)  requires  four  proofs;  in  the  typical  co  e,  however,  the  first  three  are  trivial. 
Because  of  the  scope  restrictions  mentioned  in  [Wulf76a,b],  the  only  ways  the  init  clause,  &init 
or  &next  could  affect  the  predicate  R(y,z)  are  through  y,  which  is  explicitly  passed  as  a 
parameter  to  the  form  gen,  and  through  side-effect-producing  operations  of  & i n i t and  &next. 
Thus  the  proof  c a. . be  carried  out  locally  for  the  generator  definition  --  generally  by 
inspection.  The  fourth  proof  is  more  difficult.  Because  of  the  scope  restrictions,  the  only  way 


that  the  loop  body  could  affect  the  loop  variable,  x,  is  for  the  generator  to  provide  a function 
which  could  have  a side  effect  on  x (for  example,  by  exporting  assignment  rights).  This  proof 
should  be  local  to  tht  ^erwralur  definition.  K:  i*x ver,  ffe  indopcndefiio  of  y frctm  ST  carrot  In 
general  be  shown  for  the  generator,  and  must  be  treated  as  a restriction  on  its  use. 


Simplified  Rules  for  Iteration  Statements 


If  the  generator  and  its  use  meet  the  four  basic  generator  assumptions  given  above,  a 
simplified  proof  rule  applies  to  the  for  statement:^ 


G a [P  a /3j  a -’(n|A/?(x))  v I a a -'(nnA/?(x))]  3 Q 
G a fiM  A [P  a /?j  a itj  v 1 a /3n  a nn]  { $T(x,y,z)  ) I 


P a /?req  { for  x:  gen(y)  while  /?(x)  do  ST(x,y,z)  | I } Q 

Note  that  the  first  line  establishes  that  Q holds  when  (if)  the  loop  terminates  --  which  may 
happen  immediately  after  the  invocation  of  &init  (handled  by  the  first  term  of  the  disjunction 
in  []’s>,  or  after  an  invocation  of  &next  (handled  by  the  second  term  of  the  disjunction).  In 
both  cases  termination  may  result  either  because  the  relevant  generator  function  returned 
false  or  because  /?(x)  failed  --  hence  the  terms  of  the  form  "-(n  a /?(x))".  The  second  line 
ensures  that  the  invariant  is  established  after  each  application  of  the  loop  body. 

Under  the  same  assumptions,  the  following  proof  rule  applies  to  the  first  statement: 

G a P a [/?jAnj  v /3nAnnA-/?(xQ..xp)]  a /?(x)  { Sj(x,y,z)  } Q 
G A P A On;A/I|  V -nnA/3nA-/?(x0..xp)]  { S2(y,z)  ] Q 

P a /?req  { first  x:  gen(y)  suchthat  /?(x)  then  Sj(x,y,z)  else  $2(y,z)  } Q 

where  ,,-’/?(xQ..xp)"  is  an  abbreviation  for  ”-/^?(xq)  a ...  a -’/?(xp)”.  Note  that  the  second  line 
handles  the  "else"  cases,  where  no  match  is  found;  the  two  terms  of  the  disjunction  are  the 
case  where  the  generator  terminates  immediately  and  the  case  where  every  element 
generated  fails  the  suchthat  test,  /3(x).  The  first  line  handles  the  case  where  a match  is  found. 
Note  also  that  the  presumed  independence  of  the  generator  and  the  user  program  means  that 
P is  not  affected  by  &init  and  &next. 


Simplified  Rules  for  Typical  Generators 

Most  generators  are  far  more  stylized  than  the  simple  assumptions  above  require.  The 


10 


The  justifications  of  this  and  the  first  rule,  from  the  corresponding  general  rules 


and  the  basic  generator  assumptions,  are  given  in  Appendix  B. 


following  assumptions  about  standard  aggregates  used  in  typical  generators  allow  us  to  obtain 
prcof  rules  of  further  simplicity. 

Standard  Aggregate  Assumptions 

(a)  The  additional  abstraction  provided  by  the  generator  is  explicated  in  terms  of 

an  aggregate  (of  objects  of  the  base  type)  for  which  the  following  are 
defined: 

if®  an  operator  to  combine  (e.g.,  concatenate)  two  aggregates 

<>  the  empty  aggregate 

lead(S)  = first  element  of  $ to  be  generated 

Examples  of  such  aggregates  are  sets,  sequences,  and  intervals.  The 
corresponding  empty  aggregates  are  {},  <>,  and  [];  the  corresponding  (» 
operators  are  union,  concatenation,  and  merging  adjacent  intervals. 

(b)  The  instantiation  of  the  generator  will  produce  the  complete  aggregate,  T,  of 

objects  to  be  generated.  Further,  a nonempty  T can  be  decomposed  as 

T = s s?  <x>  S3  t 

where:  <x>  is  the  unit  aggregate  consisting  of  the  current  element  x;  s and  t 
are  (possibly  empty)  aggregates  — s,  those  elements  previously  generated 
and  t,  those  remaining  to  be  generattu;  and  s,  <x>,  and  t are  mutually 
disjoint. 

(c)  The  specifications  on  &init  and  &next  have  the  form 

functions 

&init(&g:gen)  returns  &b:boolean 

post  (&b  5 T?<>)  a (&b  ^ x=lead(Y)  a Djfx)) 

&next(&g:gen)  returns  &b:boo!ean  - 
pre  02(x) 

post  (&b  ■ t7<>)  A («b  ^ x-lead(t’)  a Dg(x)) 

where  is  an  instantiation  of  gen  corresponding  to  the  aggregate  T and 
the  Dj(x)  guarantee  that  the  decomposition  of  T specified  in  (b)  is  legal  and 
can  be  found. 


The  standard  aggregate  assumptions  subsume  points  (a)  and  (b)  of  the  basic  generator 
assumptions,  but  points  (c)  and  (d)  of  the  latter  must  still  be  oemonstrated  in  addition  to  the 
standard  aggregate  assumptions. 
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If  these  assumptions  hold,  we  can  derive  several  simpler  proof  rules.  The  rule  for  the 
for  statement  becomes 

G a [P  a (T=<>  v -/?(lead(T)))  v TH<>  a I(s)  a (s=T  v -/Hx))]  a Q 
G a T/<>  a [P  a /?<lead(T))  v (s/T  a I(s)  a /3(x))]  { ST  } I<s®<x>) 


P a /3req  { for  x:  gen(y)  while  /3(x)  do  ST(x,y,z)  | I } Q 

and  the  first  rule  simplifies  to 

G a P a Vwfs  -/?(w)  A fi(x)  { S i (x,y,z)  } Q 
G a P a VwfT  ■'/2M  { s2(y,z) } Q 


P a /?req  { first  x:  gen(y)  suchthat  /?(x)  then  Sj(x,y,z)  else  S2(y>z)  } Q 
We  call  these  two  rules  the  standard  aggregate  rules. 


Special  Cases  and  Examples 


T he  Pure  [or  l 'ule 

In  many  cases  the  programmer  may  wish  to  drop  the  while  clause,  treating  /3(x)  as 
identically  true.  In  addition,  he  will  often  wish  to  choose  P = I(<:>)  and  Q = I(T).  (Until  now  the 
major  reason  for  distinguishing  between  P,  Q,  and  I was  that  if  /?(x)  terminates  the  loop  before 
the  generator  signals  termination,  I(T)  is  probably  not  true.)  If  these  decisions  are  made,  the 
proof  rule  simplifies  further,  since  the  first  premise  reduces  to  true  and  several  terms  drop 
out  of  the  second.  Making  the  substitutions  yields  a generic  rule  similar  to  those  of  various 
for  statements  given  by  Hoare  [Hoare72a]: 

G a T=sp<x>ifot  a I(s)  { ST(x,y,z)  } I(si®<x>) 


I(<>)  A /?req  { for  x:  gen(y)  do  ST(x,y,z)  } I(T) 


Proof  Rules  for  upto 

To  use  one  of  these  rules  with  a particular  generator,  we  must  "instantiate"  it  with  the 
particulars  of  the  generator  in  question.  We  will  illustrate  this  by  developing  the  proof  rules 
for  upto.  First,  we  discharge  parts  (c)  and  (d)  of  the  basic  generator  assumptions: 
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(c)  The  bodies  consist  of  simple  assignment  statements,  and  thus  clearly  terminate. 

(cl)  There  is  no  init  clause  and  functions  &init  and  &next  change  only  local  dr’ a 
and  their  return  values;  thus  the  first  three  parts  of  independence  are 
satisfied.  For  the  fourth  point,  note  that  no  means  is  provided  for  the  user 
of  the  form  to  alter  k;  the  user  is  expected  to  refrain  from  altering  lb  and 
ub. 

Next,  we  discharge  the  standard  aggregate  assumptions: 

(a)  Integer  intervals  are  used. 

(b)  [lb..ub]  = [lb..k-l][k][k+l..ub]  when  lb<k<ub. 

(c)  The  pre  and  post  conditions  have  the  required  form. 

Substituting  the  interval  definitions  in  the  standard  aggregate  rules  and  simplifying,  we  obtain 

PA(lb>ubvi/?(lb))  v lb<k<ubAl[lb..k-l]A-'/?(k)  v lb<ub Al[lb..ub]  ^ Q 
lb<ub  a (P  a /?(lb)  v lb<k<ub  a I[lb..k-1]  a /?(k))  { ST(k,y,z)  } I[lb..k] 


P { for.  k:  upto(lb,ub)  while  /?(k)  do  ST(k,y,z)  | I(k,y,z)  } Q 

and 

P a lb<k<ub  a (Vw  ( [lb..k-i]  -■/((w))  a /?(k)  { Sj(k,y,z)  } Q 
P a Vw  ( [lb..ub]  ^/?(w)  { S2(y»z)  } Q 


P { first  k:  upto(lb,ub)  suchthat  ft{k)  then  Sj(k,y,z)  else  S2(y,z)  } Q 

where  I he  y parameters  are  <lb,ub>.  In  the  special  case  P=I[],  Q=I[lb..ub],  and  /Jstrue,  we 
obtain  the  Pascal  rule  for  the  for  statement  [Hoare72a,  Hoare73]: 

lb<k<ub  a I[lb..k-1]  (ST(k,y,z)}  I[lb..k] 


I[]  { for  k:upto(lb,ub)  do  ST(k,y,z)  } I[lb..ub] 

As  must  be  the  case,  this  rule  is  also  obtained  from  the  pure  for.  rule  by  instantiating  gen(y) 
with  upto(lb,ub). 


nLrnMnu;  acrauun  ana  ueneraiurs 


rage  ci 


The  Pure  while  Rule 

We  showed  above  that  when  the  while  clause  is  dropped,  the  for  proof  rule  resembles 
Hoare’s,  We  will  now  show  how  to  eliminate  the  loop  variable  and  obtain  the  standard  proof 
rule  for  the  pure  while  statement, 

Suppose  we  had  a form  named  "forever"  which  extended  type  boolean  and  which 
satisfied  the  requirements  above  by  using  the  value  "true"  for  all  the  predicates  involved. 
The  aggregate  T would  be  an  infinite  sequence  of  "true"s,  and  the  standard  aggregate  for  rule 
would  become 

true  A fP  a (false  v -’/((true))  v true  A I(true*)  A (false  v -'/((true))]  s Q 
true  a [P  /,  /?(t rue ) v true  a Ktrue*)  a /((true)]  { ST(true„z)  } Ktrue*) 

P { for  x:  forever  while  /((true)  do  ST(true„z)  | Ktrue*)  } Q 

where  "true*"  denotes  a sequence  of  “true"s  and  the  adjacent  commas  indicate  the  absence  of 
the  parameters  y.  By  choosing  P = 1 and  Q = 1 a -/?,  eliminating  the  vacuous  dependencies  on 
"true",  dropping  the  useless  for  clause,  and  simplifying,  we  obtain 

I a fi  { ST'z)  } I 


1 { while  fi  do  ST(z)  } I a -/J 
which  is  the  conventional  while  rule. 


Generator  Spectficattons  by  Proof  Rules 

We  have  shown  how  two  sets  of  assumptions  about  the  properties  of  a generator  lead 
to  very  simple  proof  rules  for  the  iteration  statements.  Notice  now  that  if  a generator 
satisfies  these  assumptions,  the  specifications  for  ftinit  and  ((’next  can  be  reconstructed  or 
obtained  from  the  proof  rules.  As  a result,  the  author  of  the  generator  can  perform  the 
substitutions  and  simplifications,  then  give  the  proof  rules  in  the  specifications  instead  of 
giving  the  pre  and  post  conditions.  When  this  is  possible,  we  use  the  keyword  generator  in 
place  of  form  in  the  specification  to  alert  the  user. 

To  illustrate  this,  we  will  write  the  generator  for  a counting  loop  that  uses  an  integer 
step  size  greater  than  1.  This  will  provide  the  Alphard  equivalent  of  Algol’s 

for  i :=  a step  j until  b do  S 


for  positive  values  of  j.  We  first  augment  the  interval  notation  [a..b]  to  include  a step  size: 
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[a(j)b]  sLif  <a,a+j,a+2*j,  ...  ,b-(b-a)  mod  j>  where  j>0 

If  a>b,  then  [a(j)b]  is  <>.  Note  that  [a<  1 >b ] = [a..b].  The  following  rule  allows  us  to  merge  two 
intervals: 


[a(j)b][b+j(j)c]=[a(j)c]  provided  (b-a)  mod  j - 0. 

Using  this  notation,  we  can  define  the  generator  stepup 

generator  stepup  (Ib.i.uba'nteger)ex tends  k:integer  = 
beginform 
specifications 
requires  j > 0; 
inherits  < a 1 1 b u t e>; 

let  stepup  = [lb(j)ub]  where  lb<ub  p stepup  «=  flb(j)k-j][k]rk+j(i)'jb]; 

rule  forwhile(PAj>0,  k,  <lb,j,ub>,  ft,  ST(k,<lb,j,ub>,z),  I,  Q)  -• 

premise  PA(lb>ubv-/t(lb))  v lb<k<ub-dAl[lb(j)k-j]A->/?(k)  v lb<ubAl[lb(j)ub]  p Q, 
premise  lb<ub  a (PA/t(lb)  v lb<k<ub-dAl[lb(j)k-j]A/?(k))  { ST(k,<lb,j,ub>,z)  } 
I[lb(j)k]  where  d-(ub-lb)  mod  j; 

rule  fj_rst(PAj>0,  k,  <lb,j,ub>,  /?,  S j(k,<lb,j,ub>,z),  S2<<lb,j,ub>,z>,  Q)  =* 

premise  P a lb<k<ub  a (Vw  ( flb(j)k-j]  ^/?(w))  a /?(k)  { S ^(k,<lb,j,ub>,z)  } Q, 
premise  P a Vw  ( [lb(j)ub]  ->/t(w)  { S2(<lb,j,ub>,z)  } Q; 

rule  for(lAj>0,  k,  <lb,j,ub>,  ST(k,  <lb,j,ub>,  z))  = 

premise  lb<k<ub-d  a '[lb(j)k-j]  { ST(k ,<lb,j,ub>,z)  } I[lb(j)k] 
where  d=(ub-lb)  mod  j; 

representation 

j 

! same  as  upto 

I 

implem  en  tat  ion 

j 

! same  as  upto,  except  in  &next  “+1"  becomes  "+j"  and  k’<ub  becomes  k’+j<ub 

t 

endforrn 


Example  of  Loop  Verification 

In  this  section  we  shall  illustrate  the  use  of  the  proof  rules  given  above  by  verifying 
the  "eqvecs"  function  given  earlier.  With  pre  and  post  assertions,  the  function  is 
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function  eqvecs(A,B:  vector(?t<y>,?lb;?ub))  returns  (eq:  boolean)  ■ 
ere  true  post  (eq  s (Vj  ( [Ib  .ub]  A[j]-  ’"M]))  = 

first  i:  upto(lb,ub)  suchthat  A[i]  t B[ij  then  eq  <-  false  else  eq  <-  true 

Using  the  upto  first  rule,  the  proof  requires  that  we  establish  the  two  premises: 

Show:  true  A lb<i<ub  A (Vw  < [lb..i- 1 ] -,(A[y]yB[y]))  A A[i]/B[i] 

{ eq<-false  } eq  h Vj  < [lb..ub]  A[j]=B[j] 

Proof:  This  simplifies  to  lb<i<ub  A A[i]/B[i]  =>  3j  ( [lb..ub]  A[j]^B[j].  Choose  j — i. 

Show:  true  A Vw  ( [Ib.ub]  -(A[w]yB[w])  { eq*-true  } eq  5 Vj  ( [lb..ub]  AT  j ]=B[j  ] 
Proof:  clear 

QED 


Termination  of  Generators 


A major  advantage  of  the  fO£  statements  in  many  of  the  more  recent  programming 
languages,  such  as  Pascal,  is  that  they  are  guaranteed  to  terminate  (provided,  of  course,  that 
the  statement  which  is  the  loop  body  terminates  for  each  value  of  the  for.  statement).  As  a 
result  the  programmer  using  them  never  need  explicitly  demonstrate  termination.  We  wouid 
like  to  be  able  to  make  similar  claims  about  the  loops  utilizing  at  least  some  generators;  the 
generators  having  this  property  will  be  called  terminating  generators. 

We  can  now  present  a technique  for  demonstrating  this  property.  Although  the 
general  for.  statement  is 


for  x:gen(y)  while  /?(x)  d£  ST(x,y,z) 

the  clause  "while  flM"  can  only  reduce  the  number  of  times  ST(x,y,z)  is  executed.  Hence  it 
suffices  to  show  that 


tor  x:gen(y)  do  ST(x,y,z) 

terminates.  Further,  the  generator  and  loop  body,  ST(x,y,z),  are  independent,  so  we  know  that 
as  long  as  the  body  itself  terminates  for  each  x,  it  cannot  cause  the  for  statement  to  fail  to 


^ * Note  that  nontermination  of  the  loop  might  also  be  caused  by  nonterminaton  of  *he 
cnit  clause  or  the  functions  &init  and  Snext  in  the  generator.  This  is  explicitly  ruled  out  by 
the  basic  generator  assumptions,  but  must  be  treated  as  an  additional  requirement  for  proof  of 
termination  of  generators  which  do  not  satisfy  those  assumptions. 
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terminate.  Thus,  if  we  can  show  the  termination  of  the  above  statement  for  all  possible 
parameters  r ' the  generator  and  some  particular  loop  body,  we  will  have  shown  that  use  Of 
the  generator  c,  rmot  cause  nontermination  *or  any  body. 

Consider  the  statement 


i<-0;  for  x:Ren(y)  do  i<-i  + l 

If  we  could  find:  (1)  a (non-negative)  value  My  depending  only  on  y for  which  i<My  after 
executing  the  statement,  and  (2)  a loop  invariant  which  allowed  us  to  prove  that  the  loop 
terminated  with  such  a value  of  i,  then  we  would  have  proved  termination  of  .ill  loops  using 
gen. 

Clearly,  the  choice  of  My  will  depend  on  the  instantiation  parameters  of  the  generator, 
i.e.,  on  the  data  structure  from  which  the  elements  are  being  generated.  The  loop  invariant 
will  have  to  assert  that  My  bounds  i;  it  will  also  have  to  relate  the  value  of  i to  progress 
through  t hie  loop.  The  term  that  accomplishes  the  latter  task,  which  we  shall  call  Iy(x),  must  be 
chosen  for  each  generator  whose  termination  is  to  be  proved.  Thus  the  loop  invariant  is  of 
the  form  i<MyAly(x).  If  we  can  associate  with  a generator  a rule  for  determining  My  for  any 
particular  instantiation,  and  if  we  can  find  a suitable  Iy(x),  then  it  suffices  to  show^ 

i=0  { for  x:gen(y)  do  i<-i  + l | i<MyAly(x)  } i<My 

Note  that  the  clause  "i<My"  in  this  loop  invariant  ensures  that  the  loop  will  terminate,  since  i is 
strictly  increasing  from  0. 

Although  this  must  potentially  be  proved  for  each  generator,  we  can  show  the 
termination  of  every  generator  which  satisfies  the  standard  aggregate  assumptions  (with  a 
finite  aggregate),  provided  only  that  it  is  possible  to  measure  the  size  of  an  aggregate.  To 
demonstrate  this,  we  use  the  pure  for  rule  taking  J(s)  as  i<size(T)Ai=size(s),  where  "size’  is 
defined  appropriately  for  *he  aggregate.  The  only  premise 

G a T=s(®<x><®t  a i<size(T)  A i=size(s)  { i<-i  + l } i<size(T)  a i=size(s@<x>) 

follows  since  s and  <x>  are  disjoint,  whence  size(s)  < size(T)  and  size(si®<x>)  = size(s)+l. 
Hence  the  conclusion  of  the  pure  for  rule  is 

:<size(T)  a :=size(<>)  { foil  x:  gen(y)  do  i«-i+l  } i<size(T)  a i=size(T) 

This  then  implies  the  desired  result  with  My=size(T)  and  Iy(x)=size(s). 


12  This  method  for  showing  termination  is  a simple  instance  of  the  commonly-used  well- 
founded  set  notion  [Katz75,  Luckham75].  Here  the  well-founded  set  is  the  non-negative 
integers  bounded  cy  My. 


ALPHARD:  Iteration  and  Generators 


Page  25 


Example:  Finite  Sets 


We  now  turn  to  a larger  example  that  uses  the  iteration  constructs.  This  example  is 
based  on  Hoare’s  "smallintset"  [Hoare72b],  which  implements  small  sets  of  integers.  We  begin 
by  presenting  and  verifying  a slightly  augmented  version  of  "smallintset  . This  form,  called 
"simpleset",  uses  first  statements  and  the  "upto"  generator;  the  program  and  the  verification 
can  be  compared  with  Hoare’s  "smallintset".  We  then  discuss  the  problem  of  adding  new 
operations  to  "simpleset";  we  construct  a new  type  with  the  additional  operators  by  adding  a 
set-element  generator  to  "simpleset"  and  writing  a new  form  (which  extends  simpleset  ) for 
the  new  operators. 


"Simpleset":  a Version  of  Hoare's  'Smallintset 

This  differs  from  Hoare’s  "smallintset"  in  that  it  can  build  sets  of  many  types  and  the 
bound  on  the  set  size  can  be  selected  for  each  instantiation.  Hoare  noted  these  extensions  in 
[Hoare72b,  section  9].  In  addition,  the  algorithm  used  in  "remove"  is  slightly  different. 

fpi-m  simpleset(maxsize:integer,  thing:forrn<«-,=>)  = 
beginform 
specifications 

requires  maxsize  > 0; 

lei  simpleset  = { . . . xj  . . . } where  x(  is  thing; 
invariant  cardinality(simpleset)  < maxsize; 
initially  simpleset  = {}; 
function 

insert(s:simpleset,  xithing) 

pre  cardinality({x}  u s)  < maxsize 
post  s = s’  U {x}, 
remove(s:simpleset,  x:thing) 
post  s = s’  - {x}, 

has(s:simpleset,  x:thing)  returns  (b:  boolean) 
post  b = x ( s’; 


13  To  shorten  the  pre,  post,  in,  and  out  conditions  in  this  paper,  we  often,  by 
convention,  omit  assertions  about  variables  which  are  completely  unchanged.  Thus,  for 
example,  we  have  omitted  s=s’  from  the  post  condition  of  has  below.  Such  omitted  assertions 
are  nevertieless  used  in  the  proof  s s. 
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representation 

unique  v:  vector(thing,l,maxsize),  m:  integer  inj_t  m «-  0; 

rejo(v,m)  = {v[i]  | i < [l..m]}; 

invariant  0<m<maxsize  a <Vi,j  ( [l..m]  (v[i]«=v[j]  p i=j)); 
implementation 

body  insert  in  (3i  ( [l..s.m]  st  x=s.v[i]  v s.m<maxsize) 

out  (Vi([l..s.m’](s.v[ij  = s.v’[i])  A (3i  ( [l..s.m]  st  s.v[j]  = x))  = 
first  p:  upto(l,s,m)  suchthat  s.v[p]  = x 
else  (s.m  «-  s.m+1;  s.v[s.m]  «-  x); 

body  remove  oui  (Vj  € [l..s.m](s.v[j]  ft  x)  a 

(Vi  ( [l..s.m’]  3j  < [l..s.m]  (s.v’[i]  / x p s.v[j]  = s.v’[i])))= 
first  p:  upto(l,s.m)  suchthat  s.v[p]  = x 
then  (s.v[p]  s.v[s.m];  s.m  «-  s.m-1)- 

body  has  out.  (b  s pi  < [l.,s.m]  st  s.v[i]=x)  a s.v’=s.v  a s.m’=s.m)  = 
first  p;  upto(l,s.m)  suchthat  s.v[p]  = x 
then  b <-  true  else  b ♦-  false; 

endform 


Verification  of  Simpleset 


F or  the  form 

1.  Representation  validity 

Show:  0<m<maxsize  A (Vi,j  ( [l..m](v[i]=v[jjpi=j))  p 
cardinality({v[i]  | i ( [l..m]})<maxsize 
Proof:  clear 

2.  Initialization 

Show:  max$ize>0  {m«-0}  {v[i]  | i ( [l..m]}={}  A 0<m<maxsize  a 
(Vi,j<[ l..m]( . [i]=v[j]  =>  i=j)) 

Proof:  0<0<ma>:size  and  [1..0]  is  []. 

F or  the  function  insert 

3.  Concrete  operation 

Show:  /3jn  a Ic  { first  p:  upto(l,s.m)  suchthat  s.v[p]**x 
else  (s.m<-s.m+l;  $.v[$.m]«-x)}  A Ic 
Proof:  The  second  premise  of  the  upto  first  rule  becomes 
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(3i  < [I..s.m]  st  x=s.v[i]  v s.rr><maxsize)  a I£  A 
VK  ( [l..s.m](s.v[k]^x)  { s.m«-s.m+l;  s.v[s.m]«-x  } 

Vi  € [l..s.m’](s.v[i]=s.v’[i])  a (3j  ( [l„s.m]  st  s.v[j]“x)  a Ic 

The  first  term  follows  by  s.m=s.m’+l>s.m\  For  the  second  term  choose 
j=s.m  (note  l<s.m<maxsize).  The  first  term  of  Ic  holds  because  the  Vk 
term  means  s.m<maxsize  in  the  second  term  of  the  hypothesis.  The 
second  term  of  Ic  holds  from  Ic  and  the  Vk  term.  The  first  premise  of 
the  first  rule  becomes 

/?in  a Ic  a l<p<s.m  a (Vk  < [l..p-l](s.v[k]^x»  a s.v[p]=x  { j /tfou|  a Ic 

The  second  term  of  /30u{  follows  by  choosing  j^p.  The  other  terms 
are  clear. 

4a.  /?jn  holds 

Show:  Ic  a cardinality({x}Urep(v,m))  < maxsize  3 
(3i  ( [l..s.m]  st  x=s.v[i]  v s.m<maxsize) 

Proof:  From  Ic  the  v[i]’s  are  distinct.  Hence  cardinality(rep(v,s.m)) 
is  s.m.  If  the  3i  term  is  false,  then  x •’<  rep(v,s.m)  and 
cardinality({x}Urep(v,m))  = l+s.m<maxsize,  i.e.,  s.m<maxsize. 

/4p0st  holds 

Show:  Ic  a cardinality({x}urep(v’,s.m’))<maxsize  a /?ouj  :>  s - s’  u fx] 

Proof:  s - rep(s.v.s.m)  = {s.v[i]  | i ( [l..s.m]}  - 
{s.v’[i]  | i ( [l..s.m’]}  u (s.v[s.m]}  * s’  u {xj 

For  the  function  remove 
3.  Concrete  operation 

Show:  y?jn  a Ic  { first  p:  upto(l,s.m)  suchthat  s.v[p]=x 
then  (s.v[p]«-s.v[s.m];  s.m<-s.m-l)}  a Ic 
Proof:  The  second  premise  of  the  upto  first  rule  becomes 

true  a Ic  a Vk  ( [l..s.m](s.v[k]^x)  { } 

(Vj  t [l..$.m](s.v[j]/x))  a (Vi  € [l..s.m}3j  € [l..s.m](s.v’[i><x  3 
S.v[j]=S.v’[i]))  A Ic 

The  first  ter  n follows  by  the  Vk  term.  For  the  second  term  choose 
j=i.  Ic  is  clear.  The  first  premise  of  the  first  rule  becomes 

true  a Ic  A l<p<s.m  a (Vk  t [l..p-l  J(s.v[k]^x))  a s.v[p]  ■ x 
{ s.v[p]«-s.v[s.mj  s.tm-s.m-1  } /?out  a Ic 
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s.m  remains  non-negative  since  s.m’>l.  The  reasons  for  the  other 
terms  depend  on  p=s.m  or  p^s.m.  Let  p=s.m.  For  the  second  term  of 
Ic,  note  that  {s.v[l..s.m]}-{x}  = {s.v’[l..s.rrT-l]}  so  s.v’[l..mM]  is 
duplicate-free  by  Ic.  The  first  term  of  /?ouj  follows  from  the  Vk  term. 
For  the  second  term  of  choose  j=i.  Now  let  p?<s.m.  By  Ic, 

{v[l..p-l,p+l..s.m’-l JJ  u {s.v[s.m’j}  = (v[l..m]}  is  duplicate-free.  The 
first  term  of  /?0uj  follows  from  Ic  and  s.v’[p]  = x t s.v’[s.m’]  = s.v[p]. 
For  the  second  term  of  /?ouj  choose  j=i  except  when  i=m’  in  wnich 
case  choose  j=p. 

4a.  /?|n  holds 
/4jn  is  true 

4b.  ^post  holds 

Show:  Ic  a /?Qut  3 s = s’  - {x} 

Proof:  s = {s.v[i]  | i C [l..s.m]}.  By  the  first  term  of  /f?ou{, 
x -><  s and  by  the  second  term  of  /30u(,  y^x  3 y(s  iff  y(s\ 

Hence  s = s’  - {x}. 

For  the  function  has 

3.  Concrete  operation 

Show:  y?m  a Ic  { first  p:  upto(l,s.m)  suchthat  s.v[p]=x 
then  b<-true  else  b<-false  } /?ouj  a Ic 
Proof:  Ic  ic  unchanged.  The  second  premise  of  the  upto  first  rule  has 

the  hypothesis  Vk  < [l..s.mJ<s.v[k]Hx),  i.e.,  the  3 ierm  in  /?out  is  false  - 
b.  The  first  premise  has  the  hypothesis  v[p]=x,  i.e.,  choose  i=p  so  the 
3 term  is  true  = b. 

4a,  holds 
/?jn  is  true 

4b-  ^post  holds 

Show:  Ic  a 3 b = x ( s’ 

Proof:  b = 3i  C [l..s.m]  st  ($.v[i]=x)  ** 
x < {v’[i]  | i ( [l..s.m’]}=  x ( s’ 

QED 


We  noted  earlier  that  our  algorithm  for  remove  is  different  from  Hoare’s.  Since  our  /3|n 
and  ^out  can  be  used  f°r  Hoafe’5  remove,  the  proof  of  his  remove  requires  changing  only 
step  3. 


Adding  F unctions  to  " Simpleset " 

Suppose  now  that  we  wanted  to  add  other  set  operations  such  as  union,  intersection, 
and  an  inclusion  test.  We  could  do  ihis  either  by  adding  each  new  operation  to  form 
"simpleset",  or  we  could  write  a new  form,  say  "finitecet",  which  extends  "simpleset".  In  the 
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former  case  we  would  have  access  to  the  representation  of  simplesets,  but  we  would  have  to 
be  very  concerned  about  possible  side  effects  on  the  representation  and  about  the  possibility 
of  compromising  the  existing  verification.  In  addition,  each  such  change  alters  the 
specifications  of  "simpleset",  and  thus  potentially  requires  reverification  of  the  programs  that 
use  "simplesets".  The  latter  choice  substantially  reduces  the  reverification  responsibilities  and 
allows  a number  of  users  to  write  extended  operation  sets  without  interfering  with  each  other. 
However,  it  is  feasible  only  if  the  set  of  operations  provided  by  "simpleset"  is  rich  enough. 

The  version  of  "simpleset"  presented  in  the  previous  section  is  not  quite  rich  enough 
for  extended  operation  sets  to  be  independent.  The  chief  deficiency  is  that  there  is  no  way 
for  a user  to  find  out  what  elements  are  in  a set.  We  will  remedy  that  by  adding  a generator 
"inset"  to  the  simpleset  form  and  then  write  an  extension  form  "finiteset". 


"Inset":  a Set  Element  Generator 

We  said  above  that  a generator  produces  a sequence  of  elements.  Since  sets  are  not 
inherently  ordered,  we  can  generate  the  elements  in  any  order  that  is  convenient.  We  do, 
however,  want  to  be  able  to  promise  that  each  element  in  a set  appears  exactly  once  in  the 
generated  sequence.  It  is  not  necessary  (or  particularly  desirable)  that  the  elements  of  two 
equal  sets  be  generated  in  the  same  order.  In  fact,  the  order  in  which  this  generator 
produces  the  set  elements  is  an  accident  of  the  history  of  the  set.^ 

The  following  program  text  is  the  definition  of  a generator,  "inset",  which  produces  the 
desired  sequence;  it  is  shown  in  its  proper  context  within  the  "simpleset"  form.  We  have, 
however,  deleted  (and  replaced  by  ellipses)  those  parts  of  "simpleset"  which  are  identical  to 
their  previous  definition.  The  form  inset  satisfies  the  standard  aggregate  assumptions,  so  we 
specify  it  by  giving  its  proof  rules.  For  simplicity,  we  provide  only  the  first  and  the  pure  for 
rules. 


form  simpleset(maxsize:integer,  thing:form«-.*>)  * 
beginform 

specifications 

generator  inset(s:simpleset)  extends  xithing 

let  inset  = { x st  x < s } where  s / {}  ^ (inset  = qu{x)ur  and 

q,  {x },  and  r are  disjoint); 
rule  ford,  x,  s,  ST(x,  s,  z))  = 

premise  q c $ a x < s-q  A I(q)  { ST(x,s,z)  } I(q  U {x}); 


^ We  could,  of  course,  go  to  extra  trouble  to  generate  the  elements  in  a standard 
order,  but  that  is  a different  design  decision  and  leads  to  a different  program. 
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rule  first(P,  x,  s,  /?,  Sj(x,  s,  z),  Sjfs,  z),  0)  B 

premise  q c s a x < s-q  A P A (V w ( q ->/3(w))  a $(x)  { Sjfx.s.z)  } Q, 
premise  P a Yw  ( s -</?(w)  { Sjfs.z)  } Q; 

implementation 


body  inset  = 
beginform 
representation 

unique  j:integer; 

rep(s.v.s.m,x,i)  = [f  s.m=0  then  {}  else  q U (x)  U r where 
q = {s.v[i]  | i < [1..J-1]}  and 
x = s.v[j]  and 
r = {s.v[i]  | i < [j+l..m]}; 
invariant  true; 
implementation 

body  &init  out  ((&b  * s.m>0)  a (&b  o l=&g.j<s.m  a x=$.v[&g.j]))  ■ 
if  s.m  > 0 then  (&g.j«-l;  x<-s.v[l];  &b«-true) 
else  &b*-false; 

body  flnext  in  l<&g.j<s.m  out  ((&b  £ &g.j’  < s.m)  a 
(&b  =>  &g.j=&g.j’+l  a l<&g.]<s.m  a x=s.v[&g.j]))  = 
if  &g.j  < s.m  then  (&g.j<-&g.j+lj  x<-$.v[&g.j];  &b«-true) 
else  &b«-false; 

endform 

endform 


The  generator  "inset"  can  now  be  used  to  express  the  iteration  which  was  posed  as  the 
first  problem  in  the  introduction,  that  is,  to  compute  the  sum  of  the  elements  in  a set  s. 
Compare  this  Alphard  statement  with  the  three  versions  in  contemporary  languages  given 
there: 


sum  r-  0;  for,  x:inset(s)  do  sum  n-  sum  + x 

This  version  of  the  loop  does  not  reveal  the  implementation,  so  the  users  neeu  not  be 
concerned  with  which  Kind  of  iteration  is  most  appropriate.  In  addition,  the  implementor  of  the 
"simpleset"  form  can  now  be  reasonably  sure  that  a change  in  the  implementation  will  not 
create  havoc  in  user  programs.  We  can  verify  this  program  segment  using  the  pure  for.  rule 
for  inset  given  in  the  specifications. 
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Show:  true  { sum*-0;  for_  x : inset(s)  do  sum«-sum+x  } sum  = SIGMAj(s(j) 

Proof:  I({})  is  sum  = 0,  I(q)  is  sum  = SIGMAJ(q(j),  and  tne  premise  of  the  for  rule  is 
q c s A x ( s-q  A I(q)  { sum<-sum+x  } l(q  U {x}) 

This  reduces  to  the  provable  formula 

q c s A x ( s-q  A sum  = SlGMAj(q(j)  =>  sum  + x = $IGMAj(qU£xj(j) 


QED 


We  next  verify  inset.  We  must  first  reconstruct  the  pre  and  post  conditions  for  &init 
and  &next  from  the  specified  proof  rules: 

&init 

post  (&bHs;*{})  A (&b  =>  x < s A q={}) 

&next 
pre  x<s 

post  (ftbsrVU)  a (&b  ^ x < r’  A q=q’u{x’}) 

The  reasons  that  parts  (c)  and  (d)  of  the  basic  generator  assumptions  hold  are  essentially  the 
same  as  for  upto.  It  is  also  necessary  to  discharge  the  standard  aggregate  assumptions: 

(a)  Sets  are  used. 

(b)  s = q u (x)  u r when  s?<{}  (recall  disjointness  of  q,  {x},  and  r). 

(c)  The  pre  and  post  conditions  have  the  required  form. 

Since  "m"  and  "v"  are  unchanged  by  inset,  the  Ic  of  simpleset  still  holds  and  will  be  used 
throughout  this  proof.  The  qualifier  is  sometimes  omitted  in  the  interest  of  clarity. 

F or  the  form 

1.  Representation  validity 
Show:  true  ^ true 
Proof:  clear 

2.  Initialization 

Show:  true  { } true  a true 
Proof:  clear 

F or  the  function  &init 

3.  Concrete  operation 

Show:  true  { if  $.m>0  then  (&g.j<-l;  x<-$.v[l];  &b<-true)  else  &b<-fal$e  } /?ouj  a true 
Proof:  clear  by  considering  the  two  cases  of  the  if 
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4a.  /?m  holds 

fl\n  i?  true' 

4b.  ^post  holds 

Show:  true  a (&b£s.m>0)  A (&b  ^ l-&g.j<s.m  a x=s.v[&g.j])  3 (&b  2 s^{))  A 
(&b  3 x ( s a q = {}> 

Proof:  To  obtain  s and  q in  terms  of  concrete  variables,  use  the  re£ 

function.  Then  &b  s (s.m>0)  £ {v[i]  | i < [l..m]}^{}  = s^{}.  Suppose 
s.m>0,  i.e.,  &b  = true.  Then  &g.j=l  whence  x=s.v[l]  ( {v[i]  | i i [l..m]} 
and  q = {v[i]  | i < [1..0]}={}. 

F or  the  function  &next 
3.  Concrete  operation 

Similar  to  &imt.3 
4a.  /3jn  holds 

Show:  x < s ^ l<&g.j<s.m 

Proof:  Using  the  function,  x(s  implies  v[j]  ( {v[i]  | i < [l..m]}, 
whence  l<&g.j<m 
4b.  ^post  holds 

Show:  x c s a (&b£&g.j’<s.m)  A (&b  =>  &g.j=&g.j’+lAl<&g.j<s.mAx=s.v[&g.|])  ^ 
(&b  £ {v[i]  | 1 < [j’+l.  rn]}  t {})  a (&b  ^ x ( {v[i]  | i < [j’+l  m]}  a 
{v[i]  | i < [l..j-l]}={v[i]  | i < [l--j’]}> 

Proof:  &b  £ (&g.j’<s.m)  s {v[i]  1 i ( [j’+l..m]}  i {} 

by  reasoning  similar  to  4a.  The  second  term  of  the  conclusion  follows 
from  l<&g.j=&g.j’+l<s.m  and  x=s.v[&g.j]. 

QED 


"Finite  set":  an  Extension  of  "SimpLeset" 

Since  the  simple  set  form  defined  above  does  not  provide  the  usual  set  operations  one 
expects  (e.g.,  union),  in  this  section  we  shall  define  and  verify  an  extension  of  that  form  which 
provides  these  facilities.  All  of  the  mechanisms  used  in  this  example  have  been  presented 
previously;  the  example  does,  however,  provide  us  the  opportunity  to  illustrate  the  use  of  the 
specifications  of  one  form,  "simpleset",  in  the  verification  of  another.  The  new  form  definition 
and  its  proof  are  given  below: 
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form  finiteset(maxsize:integer,  T:form<*-.=>)  extends  s:simpieset(maxsize,T)  * 
beginform 
specitications 

requires  maxsize  > 0 

let  finiteset  ■■{...  Xj  ...  } where  xj  is  thing; 
invariant  cardinality(finiteset)  < maxsize; 
initially  finiteset  = {}; 
function 

union(sl,s2:finiteset(maxsize,T))  returns  s3:finiteset(maxsize,T) 
pre  cardinality(slUs2)Smaxsize 
post  s3=sl  U s2, 

intersect(sl,s2:finiteset(maxsize,T))  returns  s3:finiteset(maxsize,T) 
post  s3=sl  0 s2, 

includes(s  l,s2:finiteset(maxsize,T))  returns  b:booiean 
post  b=s2  £ si; 

representation 
rep(s)  = s 

invariant  cardinality(s)  < maxsize 

implementation 

body  union  = 
begin 

for  x:inset(sl)  do  insert(s3,x); 
for  x:inset(s2)  do  insert(s3,x); 
end; 

body  intersect  = 
for  x:inset(sl)  do 

if.  has(s2,x)  then  insert(s3,x); 
body  includes  ** 

first  x:inset(s2)  suchthat  -hasfs  1 ,x)  then  b<-false  else  b+-true; 

endform 


Verification  of  Finiteset 

Since  rep(s)  is  an  identity  function  except  for  a type  change  from  simpleset  to  finiteset, 
we  shall  assume  /3pre  = /3m  and  /'post  = /?out  in  the  proof.  All  the  generator  uses  are 
independent  of  the  loop  bodies;  specifically,  s3  is  changed  but  never  generated.  Note  also 
that  s3  is  instantiated  as  a simpleset  whenever  it  is  needed  for  a return  value,  and  hence  is 
initialized  to  {}. 


Page  34 


Example:  Finite  Sets 


F or  the  form 

1.  Representation  validity 

Show:  cardinality(s)<maxsize  o cardinality(s)  < maxsize 
Proof:  clear 

2.  Initialization 

Show:  maxsize>0  { } s={}  a cardinality(s)<maxsize 

Proof:  The  notation  refers  to  the  initially  clause  of  simpleset. 

The  proof  is  trivial. 

For  the  function  union 

3.  Concrete  operation 

Show:  cardinalityfsl Us2)<maxsize  A Ic  { body  of  union  } s3=slus2  A Ic 
Prorf:  Ic  remains  true  because  it  is  unchanged.  A loop  invariant  for  the 
first  for;  statement  is  s3  = q.  Since  cardinality(q)  < cardinalityfsl ) < 
cardina!ity(slus2)  < maxsize,  the  pre  condition  of  insert  is  met;  the 
post  condition  says  s3  = q u {x}  which  shows  s3  = q is  indeed  a loop 
invariant.  Similarly,  a loop  invariant  for  the  second  for  statement  is  s3 
= si  U q.  The  first  for  statement  is  started  with  s3  = {};  the  second 
lor  statement  is  started  with  s3  = si  by  the  result  of  the  first  for 
statement,  which  is  s3  = si. 

4a.  holds 

^pre  = An 
4b-  *post  holds 
^post  = ^out 


For  the  function  intersect 
3.  Concrete  operation 

Show:  Ir  { body  of  intersect  } s3  = slns2  a Ic 

Proof:  A loop  invariant  is  s3  = q n s2  because  if  x C s2  then  $3u{x}  = 

(q0s2)u{x}  = (qu{x})ns2  while  if  x < s2  then  s3  = qns2.  The  pre 
condition  for  insert  holds  because  s3  = qds2  c slns2  £ slus2.  The 
initialization  of  s3  to  {}  starts  the  loop  properly;  the  result  is  $3  - 
slns2, 

4a.  and  4b.  As  in  union. 
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For  the  function  includes 
3.  Concrete  operation 

Show:  Ic  { body  of  includes  } b = s2  £ si 

Proof:  The  second  premise  of  the  first  rule  has  the  hypothesis 

Vw  c s2  -’-’has(sl,w)  = (s2  £ si)  = true.  The  first  premise  has  the 
hypothesis  x ( s2  a -’(has(sl,x)),  i.e.,  x ( s2  A x ■>(  si  whence  b = false 
as  the  body  does. 

4a.  and  4b.  As  in  union. 

QED 


A Remark  on  Program  Size 

We  are  aware  of  (and  have  occasionally  shared)  the  apprehension  of  some  of  our 
colleagues  that  Alphard  programs  will  be  substantially,  even  unreasonably,  larger  than 
programs  for  similar  tasks  written  in  other  languages.  Early  results  indicate  that  this  need  not 
be  the  case.  One  comparison  is  made  in  [Shaw76];  we  are  now  able  to  compare  Hoare’s 
"smallintset"  with  "simpleset". 

First,  let  us  compare  this  program  text  with  Hoare’s.  The  Alphard  program,  "simpleset", 
initially  looks  longer  --  32  lines  to  28  for  Hoare’s  "smallintset".  "Simpleset",  however,  includes 
about  14  lines  of  verification  assertions.  With  the  exception  of  the  in/out  assertions,  this 
information  appears  in  Hoare’s  paper,  but  not  in  the  "smallintset"  program  tself. 

We  will  compare  program  sizes  (exclusive  of  assertions)  on  the  basis  of  the  number  of 
lexemes  used,  since  the  division  into  lines  is  arbitrary.  We  divided  the  lexemes  into  three 
categories:  declarations  and  procedure  headers,  text  grouping  symbols  like  begin  and  end,  and 
executable  statements.  We  treated  a qualified  name  as  a single  lexeme.  We  found  the 
following: 


executable 

grouping 

declaration 

total 

"simpleset" 

95 

2 

81 

178 

"smallintset" 

121 

12 

58 

191 

Alphard’s  shorter  executable  text  is  largely  attributable  to  the  conciseness  of  the  first 
statement;  its  larger  declaration  text  seems  to  arise  from  the  separation  of  specifications  from 
procedure  bodies  and  from  the  additional  generality.  The  differences  are  not  large  enough  to 
draw  major  conclusions  from  the  data,  and  raw  text  length  is  hardly  the  major  criterion  for 
comparing  languages.  Nonetheless,  the  closeness  of  the  numbers  should  serve  to  allay  any 
fears  that  Alphard  programs  will  necessarily  be  very  large. 
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Conclusions 


The  ultimate  goal  of  the  Alphard  project  is  to  increase  the  quality  and  reduce  the  total, 
lifetime,  cost  of  real  programs.  Of  the  many  alternative  approaches  to  this  goal  we  have 
chosen  one  in  which  recent  results  from  programming  methodology  and  program  verification 
are  merged  in  a programming  language  design, 

The  key  component  of  this  merger  is  the  introduction  of  a language  mechanism,  the 
form,  to  provide  explicit  support  for  the  development  of  conceptual  abstractions.  The  close 
association  between  forms  and  our  intuitive  notion  of  abstraction  seems  sound  on 
methodological  grounds,  for  it  permits  the  programmer  to  concentrate  on  abstractions  instead 
of  their  implementations.  It  also  seems  sound  in  terms  of  current  (and  projected)  verification 
technology  in  that  it  permits  isolated  proofs  of  manageable  size  which  collectively  verify  the 
entire  program. 

The  success  of  this  approach  to  improving  quality  and  reducing  costs  depends,  in  large 
measure,  on  the  degree  to  which  the  proposed  language  mechanism  is  able  ' i express  natural 
abstractions.  In  a previous  report  [Wulf/6a,b]  we  dealt  with  abstraction*  - hose  behavior  is 
naturally  expressed  as  a collection  of  operations  defined  over  an  abstract  data  structure.  This 
is  not,  however,  the  full  range  of  behaviors  implicit  in  our  understanding  of  the  concept  of 
"abstraction".  Thus,  in  this  report  we  concerned  ourselves  with  that  class  of  behaviors 
corresponding  to  the  notion  of  enumerating  the  elements  of  an  abstract  aggregate  (i.e.,  data 
structure). 

The  specific  content  of  this  report  has  dealt  with  two  related  issues:  the  language 
features  for  defining  ar.d  using  such  abstractions  and  the  development  of  specification  and 
verification  techniques  to  accompany  the  language  features.  It  is  reassuring  to  us  that  the 
existing  form  mechanism  is  adequate  to  capture  the  new  class  of  abstractions  introduced  here 
We  also  find  it  interesting  that  ‘he  forms  which  define  generators  can  be  specified  quite 
naturally  in  terms  of  proof  rules  instead  of  the  usual  functional  specifications.  Despite  the 
complexity  of  the  full  gener;  tor  mechanism  and  associated  proof  rules,  a chain  of  simplifying 
assumptions  yields  the  simple  rules  for  common  types  of  loops  in  other  languages; 
furthermore,  these  common  loops  terminate. 

A number  of  open  problems  remain.  The  loop  specialization  facility  in  Alphard  has  made 
it  possible  to  encapsulate  iteration  patterns  along  with  other  properties  of  an  abstraction,  but 
it  has  also  made  it  awkward  to  write  certain  kinds  of  loops,  including  those  which  operate  on 
only  part  of  a structure  and  those  in  which  a structure  is  modified  by  the  loop  which  operates 
on  if. 


We  may  wish  to  eliminate  many  such  irregular  loops  on  methodological  grounds,  but 
others  seem  to  be  reasonable,  understandable,  and  hence  safe.  For  example,  it  seems 
acceptable  to  write  loops  for 
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- recurrence  relations  in  which  the  first  k elements  of  a vector  are  treated 

individually  and  the  rest  uniformly, 

- operations  on  matrices  in  which  the  boundary  values  receive  special  treatment, 

- tree  walks  in  which  data  values  at  the  nodes,  but  not  the  tree  structure,  are 

changed, 

- list  processing  operations  when  the  locp  body  is  making  insertions  and  deletions 

to  the  list  from  which  elements  are  being  generated,  and 

- operations  in  which  the  loop  body  may  wish  to  request  early  loop  termination 

(wi\hout  ihe  distributed  cost  and  complexity  of  including  the  test  in  the  while 

clause). 

Since  a generator  is  in  fact  a form,  the  ability  to  write  some  of  these  loops  may  be  provided 
by  defining  ^unctions  other  than  &init  and  &next  in  the  generator.  Operations  on  the  structure 
would  then  still  be  performed  only  by  the  generator,  which  could  presumably  keep  matters  in 
hand.  The  restrictions  under  which  this  is  reasonable  are  a subject  for  further  research.  This 
is  not,  however,  an  acceptable  general  solution,  for  it  would  require  the  generator  to  provide 
its  own  versions  of  all  interesting  operations  on  the  structures  for  which  it  generates 
elements. 

A general  solution  for  the  problem  of  permitting  interactions  between  the  generator  and 
the  loop  body  can  be  found  by  returning  to  the  original  proof  rule,  without  even  the  basic 
generator  assumptions.  This  rule  assumes  only  that  &init  and  &r,ext  are  functions  provided  by 
the  generator.  This  solution  is  too  general  --  it  is  too  unwieldy  for  any  but  the  most  intricate 
of  interactions.  We  believe  that  a promising  path  for  further  research  is  the  search  for  sets 
of  reasonable  assumptions  which  permit  interesting  interactions  and  also,  like  the  two  sets  of 
assumptions  made  in  this  report,  lead  to  vastly  simplified  proof  rules. 
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Appendix  A 

Informal  Description  of  Verification  Methodology 


Alphara’s  verification  methodology  is  designed  to  determine  whether  a form  will  actually 
behave  as  promised  by  its  abstract  specifications.  The  methodology  depends  on  explicitly 
separating  the  description  of  how  an  object  behaves  from  the  code  that  manipulates  the 
representation  in  order  to  achieve  that  behavior.  It  is  derived  from  Hoare’s  technique  for 
showing  correctness  of  data  representations[Hoare72b]. 

The  abstract  object  and  its  behavior  are  described  in  terms  of  some  mathematical 
entities  natural  to  the  problem  domain.  Graphs  are  used  in  [Shaw76]  to  describe  binary  trees; 
sequences  are  used  in  [Wulf76a,b]  to  describe  queues  and  stacks  and  in  [London76]  to 
describe  list  processing,  and  so  on.  We  appeal  to  these  abstract  types: 

- in  the  invariant,  which  explains  that  an  instantiation  of  the  form  may  be  viewed 

as  an  object  of  the  abstract  type  that  meets  certain  restrictions, 

- in  the  initially  clause,  where  a particular  abstract  object  is  displayed,  and 

- in  the  pre  and  post  conditions  for  each  function,  which  describe  the  effect  the 

function  has  on  an  abstract  object  which  satisfies  the  invariant. 


The  form  contains  a parallel  set  of  descriptions  of  the  concrete  object  and  how  it 
behaves.  In  many  cases  this  makes  the  effect  of  a function  much  easier  to  specify  and  verify 
than  would  the  abstract  description  alone. 

Now,  although  it  is  useful  to  distinguish  between  the  behavior  we  want  and  the  data 
structures  we  operate  on,  we  also  need  to  show  a relationship  that  holds  between  the  two. 
This  is  achieved  with  the  representation  function  rep(x),  which  gives  a mapping  from  the 
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concrete  representation  to  the  abstract  description.  The  purpose  of  a form  verification  is  to 
ensure  that  the  two  invariants  and  the  rep(x)  relation  between  them  are  preserved. 

In  order  to  verify  a form  we  must  therefore  prove  four  things.  Two  relate  to  the 

representation  itself  and  two  must  be  shown  for  each  function.  Informally,  the  four  required 

, 15 

steps  are 

For  the  form 

1.  Representation  validity 

lc(x)  =>  Ia(rep(x)) 

2.  Initialization 

requires  { init  clause  } initially(rep(x))  A Ic(x) 

F or  each  function 

3.  Concrete  operation 

in(x)  A I (x)  { function  body  { out(x)  A I£(x) 

4.  Relation  between  abstract  and  concrete 

4a.  I (x)  a pre(rep(x))  o in(x) 

4b.  I (x)  a pre(rep(x’))  a out(x)  o post(rep(x)) 

Step  I shows  that  any  legal  state  of  the  concrete  representation  has  a corresponding  abstract 
object  (the  converse  is  deducible  from  the  other  steps).  Step  2 shows  that  the  initial  state 
created  by  the  representation  section  is  legal.  Step  3 is  the  standard  verification  formula  for 
the  concrete  operation  as  a simple  program;  note  that  it  enforces  the  preservation  of  lc.  Step 
4 guarantees  (a)  that  the  concrete  operation  is  applicable  whenever  the  abstract  pre  condition 
holds  and  (b)  that  if  the  operation  is  performed,  the  result  corresponds  properly  to  the 
abstract  specifications. 


Appendix  B 

Derivations  of  Simplified  Proof  Rules 


In  this  Appendix  we  show  that  the  general  for  and  first  proof  rules  and  the  basic 


15  We  will  use  Ia(rep(x))  to  denote  the  abstract  invariant  of  an  object  whose  concrete 
representation  is  x,  Ic(x)  to  denote  the  corresponding  concrete  invariant,  italics  to  refer  to 
code  segments,  and  the  names  of  specification  clauses  and  assertions  to  refer  to  those 
formulas.  In  step  4b,  "prefrepfx1))"  refers  to  the  value  of  x before  execution  of  the  function. 
A complete  development  of  the  form  verification  methodology  appears  in  [Wulf76a,b]. 
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generator  assumptions  yield  the  simplified  proof  rules  based  on  those  assumptions.  We  shall 
use  the  following  two  sets  of  assumptions  and  three  proof  rules: 

Generator  Assumptions 

(Gl)  G a /?initpre  { n - x.&init  } G a /?jnit  post 
(U2)  G a /3next_pre  { n «-  x.&next  } G a /^neyt.Post 
(G3)  /?req  { init  clause  } G 


Basic  Generator  Assumptions 

(BG1)  The  post  conditions  on  &init  and  &next  are  of  the  form 
(b  s nj)  a /?j  and  (b  s nn)  a 

respectively,  where  b is  the  result  parameter  of  these  functions. 

(BG2)  G ^ /?jnjt.pre.  G A (rtjMjnit .post  ^ nnA^next.post*  3 ^next.pre 

(BG3)  The  generator  and  the  loop  body  are  independent.  That  is,  for  arbitrary 
predicates  R and  S 

R(y,z)  { init  clause  } R(y,z) 

R(y,z)  { n <-  x.&init  } R(y,z) 

R(y,z)  { rt  <-  x.&next  } R(y,z) 
and  S(  <,y)  { ST(x,y,z)  } S(x,y) 


And  Rule 

pl  { s } Qi,  P2  { S }Q2 


Pi  A P2  { S } Ql  a Q2 


Consequence  Rules 
P =>  Q>  Q { S } R 


P { S } R 

Q { s } R,  R =>  T 


Q { s } T 
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Semicolon  Rule 

P { Si  } Q,Q  { S2  } R 
p { Sjj  S2  } R 


Let  us  work  initially  on  the  for.  statement,  its  general  proof  rule  is 

(GforO)  P A /treq  { cnit  clause  } P A /<m|t  pre 
(Gforl)  P a G a pre  { n <-  x.&init  } ->(nA/?(x))  3 Q 

(Gfor2)  P a G a pre  { n <-  x.&init;  assume  nA/?(x);  ST(x,y,z)  } I a G a /3next  pre 

(Gfor3)  I a G a /^next.pre  { n x-&nex*  } ^(ha/?(x))  3 Q 

(Gfor4)  I a G a /^next.pre  { n x&next>  assume  nA/3(x);  ST(x,y,z)  )IaGa  ^next.pre 

P a /?req  { for  x:  gen(y)  while  /?(x)  do  ST(x,y,z)  | 1 } Q 
and  the  simplified  proof  rule  is 

(Sforl,  Sfor2)  Ga[Pa/I;A  v I a fln  a -(nnA/?(x))]  3 Q 

(Sfor3,  Sfor4)  G a /?(x)  a [P  a /t|  a n,  v I a /ln  a nn]  ( ST(x,y,z)  } I 

P a /3req  { fox  x:  gen(y)  while  /?(x)  do  ST(x,y,z)  | I } Q 


Our  task,  therefore,  is  to  derive  each  of  the  five  Gfor  premises  from  G,  BG,  and  the  four 
Sfor  premises.  If  we  do  this,  we  obtain  the  conclusion  of  the  general  rule  which  is  the 
conclusion  of  the  simplified  rule.  Note  that  the  Init  clause  in  GforO  is  invoked  when  the 
generator  is  instantiated  by  the  clause  "local  x:gen(y)"  in  the  expansion  of  the  for  statement. 

We  first  note  relationships  involving  x.&next,  x.&init,  the  invariant  I,  and  the  assertion  P. 
Assumption  BG1  means  that  for  an  arbitrary  predicate  R involving  the  set  of  generated  values 
XQ,...,Xp,  and  x (in  this  notation  x is  also  denoted  by  xp+j),  we  know 

R({x0,..,xp,x})  { n «-  x.&next  } R({x0,...,xp,xp+1})  a (nn  =>  x=xp+2) 

R({})  { n <-  x.&init  } R({})  a (nj  = x=xQ) 

Thus,  provided  x is  denoted  by  xp  + j,  the  predicate  R is  preserved  by  x.&next  and  x.&init,  and 
there  may  be  a newly  generated  value.  Using  both  BG1  and  BG3  we  see  that  x.&next 
preserves  the  invariant  I,  which  depends  on  x,  y,  and  z.  The  cases  of  the  init  clause  and 
x.&init  preserving  P are  simpler  since  P depends  only  on  y and  z. 
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Derivation  of  CforO 
/?req  ( ‘-n‘'t  clause  } G 
P { init  clause  } P 
P a /?re q { init  clause  } P A G 

G 0 Anit.pre 

P a /?req  { init  clause  } P A /?injt.pre 
Derivation  of  Gforl 

G A /^init.pre  t " «-  x.&init  } G a /?init.post 
P { n <-  x.&init  } P 

P a G a /?jnjt  pre  { n «-  x.&init  } G a P A /?init  post 
G a P a (n=n|)  a^3  -KnA/?(x))  =>  Q 
P a G a /?jnit  pre  { n <-  x.&init  } -(nA/?(x))  =>  Q 


G3 

BG3 

and  rule 


BG2 


consequence 


G1 

BG3 

and  rule 
Sforl 

consequence,  BG1 


Derivation  of  Gfor2 

P a G a /?init  pre  { n «-  x.&init  } G a P a /?ini{ipos{ 

G a P a (nsn,)  a /!,  a n,  a /?(x)  = G a P a (nsrtj)  a ft-  a a ft(x) 

G a P a (nsn()  a /?j  { assume  nA/?(x)  } G a P a (n^rt;)  a ftt  A n(  a ft{x) 

G a P a (n^nj)  a /?j  a rij  a /?<x)  { ST(x,y,z)  } I a n( 

G A ^init.post  l ST(x,y,z)  } G a /?jnit.post 

G a P a (n«nj)  a /?|  a nj  a ft{x)  { SKx.y.z) ) I a G a n(  a /.?jnitpost 

G a P a (n=n|)  a ft-  { assume  nA/i(x);  ST(x,y,z)  } I a G a rtj  a /^jnjt.post 

G a nj  a /^init.post  J ^next.pre 

P a G a pre  { n <-  x.&init;  assume  rtA/?(x);  ST(x,y,z)  } 

I a G a /^next  pre 


step  3 above 
identity 
assume  rule 
Sfor3,  private  rtj 
BG3 

and  rule 
semicolon  rule 
BG2 

semicolon  rule, 
consequence,  BG1 


Derivation  of  Gfor3 

G A /Wx t.pre  ( n *■  x&next  } G A Aiext.post 
I [ n «-  x.&next  } I 

I a G a /3next.pre  { n x.&next  } G a I a /?next  pos{ 
G a I a (nsnn)  a /?n  3 An/\ft(x))  ^ Q 
I a G a /?next.Pre  t n «-  x.&next  } -(nA ft(x))  o Q 


G2 

BG1,  BG3 
and  rule 
Sfor2 

consequence,  BG1 


Derivation  of  Gfor4 

I a G A /?next  pre  ( n <-  x.&next  } G a I a /3next  pDst 

G a I a (n=nn)  a a nn  a ft{x)  G a I a <n5nn)  a y?n  a nn  a ft(x) 

G a I a (n=nn)  a ftn  { assume  nA/?(x)  } G a I a (nsnn)  a /3n  a nn  a ftix) 

G a I a (nsnn)  a ftn  a nn  a ft(x)  { ST(x,y,z)  } I a nn 


G A /^next.post  f ST(x,y,z)  } G a /^ne xt.post 

G a I a (nsnn)  a /?n  a nn  a ft{x)  { ST(x,y,z)  } I a G a nn  a /?next.post 
G A I A (nr  n)  a /?n  { assume  nA/?(x);  ST(x,y,z)  } I a G a nn  a /?next.post 

G a nn  a /ffnext.post  3 ^next.pre 

I a G a /?next.pre  ( n «-  x.&next;  assume  nA/3(x);  ST(x,y,z)  } 

I a G a /4next.pre 


step  3 above 
identity 
assume  rule 
Sfor4,  private  nn 
BG3 

and  rule 
semicolon  rule 
BG2 

semicolon  rule, 
consequence,  BG1 
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We  now  work  on  the  first  statement.  The  expansion  of 

first  x:gen(y)  suchthat  /?{x)  then  Sj(x,y,z)  else  $2(y.z) 
using  a standard  while  statement,  including  the  most  general  case  assertions,  is 

assert  p a /?req; 

begin  label  X; 

begin  local  x:  gen(y); 

asseri  P a G a /?mit  pre; 

n «-  x.&iinit; 

while 

[assed  P a G a -/?(xQ..xp)  a (n^/3nex|  pre)  a ($njt-post  v /^next.post^ 
n do 

if  /?(x)  then  (Sj(x,y,z);  goto  X)  else  n *-  x.&next 

end; 

S2(y,z); 

X:  end; 
assert  Q 

The  general  proof  rule  for  the  first  statement  is 

(GfirstO)  P A /?req  { mit  clause  } P A pre 

(Gfirstl)  P a G a /4init  pre  { n <-  x.&init  } P a G a (n=>/?next  pre) 

(Gfirst2)  P a G a ^(x0..xp)  a </?init.post  v /?next.post>  a /Snext  pre  a n a /?<x) 

{ S^x.v.z)  } Q 

(Gfirst3)  P a G a ^(x0..xp)  a (/?initpost  v /?nextpost)  A -^n  {S2(y,z)  } Q 

(Gfirst4)  P a G a -'/!(xQ..xp)  a /^next  pre  a -yf?(x)  { n <-  x.&next  } 

PAGA#0.,xptl)A(n=/!nextpre) 

P a /?req  { first  x:gen(y)  suchthat  /3(x)  then  Sj(x,y,z)  else  S2<yiZ)  } Q 

and  the  simplified  proof  rule  is 

(Sfirstl)  G a P a [/^An,  v /?nAnnA-'/rf(xQ..xp}]  a /?(x)  { Sj(x,y,z)  } Q 
( Sf irst 2)  G a P a [-njA^j  v -nnA/?nA-./?(x0,.xp)]  { S2(y,z)  } Q 


P a /?req  { first  x:  gen(y)  suchthat  /?<x)  then  Sj(x,y,z)  else  S2<y.z)  } 0 


In  Gfirstl  note  that  there  is  no  xp  before  the  statement  rr  <-  x.&init  so  -’/?(xQ.,xp)  s true. 
As  in  the  fox  case,  the  task  is  to  derive  each  of  the  five  Gfirst  premises  from  G,  BG,  and  the 
two  Sfirst  premises. 


ALPHARD:  Iteration  and  Generators 
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Derivation  of  CftrstO 
Same  as  derivation  of  GforO 


Derivation  of  C first  1 


G A ^init.pre  'l  n ) G A ^init.post 

P { n x.&init  } P 

P A G A ^imt.pre  ( n «"  x^init  > G A P A /?in)t  post 
G a P a /?jnit .post  3 P a G a (n=>/?next  pre) 

P a G a /^j nj t .pr e ^ ^ ,■  P a G a v n ^ t .pre) 

G1 

BG3 

and  rule 
BG2 

consequence 

Derivation  of  Gfirst2 

G a P a [/S|  a Hj  a true  v /?n  a nn  a -’/I(xQ.  Xp)]  a /?(x)  { Sj(x,y,z)  } Q Sfirstl 

P a G a -./3(x0..Xp)  A [(nsnj)  a v (nsnn)  a /!n]  a it  a /?(x)  { S^x.y.z)  } Q algebra 

P a G a ^(x0..xp)  a (/?jnjt  post  v /3next.post)  a n a /?<x)  { S j(x,y,z)  } Q BG1 

P a G a -■/4(xQ..Xp)  a nit.post  v ^Viext.posP  A ^next.pre  A n A AM 

{S1<x,y,z)}Q  consequence 

Derivation  of  Gfirst3 

G A P a [-'Rj  A /?|  a true  v -nn  a /?n  a -/4(xQ..xp)]  { S2(y»z>  } Q 
P a G a -^(xg-Xp)  a [(n^n,)  a /?j  v (nsn^)  a /?n]  a -^n  { S2(y,z)  ) Q 
P a G a -^(XQ.-Xp)  a post  v /^next.post)  A "n  ^ ,z ) ^ ^ 

Sf  irst  2 

algebra 

BG1 

Derivation  of  Gfirst4 

G A ^next.pre  t " «"  *-*next  ) G A ^next.post 
P { n <-  x.&next  } P 

-/?(x0..xp)  a -/?(x>  { n «-  x.&next  } -/4(x0..xp+i) 

G2 

BG3 

BG1,  definition 

_ £ /I/..  V 

of  v?(x0..xp) 


P a G A ^(XQ.-Xp)  a v?(x)  A /3nextip,.e  { n «-  x.&next  } 

P a G a /?nextpost  A ^<x0..xp+1)  and  rule 
P a G A ->/?(xQ..xp)  A /?next  pre  a i/?(x)  { n *-  x.«- next  } 

P A GA#0..xpt|)  a (n^next  pre)  BG2,  consequence 


